REST 软件架构风格学习笔记

<h2><a href="http://blog.joycode.com/ghj/archive/2009/11/26/115788.joy" target="_blank" >REST 软件架构风格学习笔记</a></h2>
        <br>REST 是 Representational State Transfer 的简称，是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。 </p>  <p>REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。</p>  <p>这些条件和原则包括:</p>  <p><strong>网络上的所有事物都被抽象为资源（resource）； </strong></p>  <p>资源是一个有趣的概念实体，它向客户端公开。资源的例子有：应用程序对象、数据库记录、算法等等。</p>    <p><strong>每个资源对应一个唯一的资源标识符（resource identifier）； </strong></p>  <p>每个资源都使用 URI (Universal Resource Identifier) 得到一个惟一的地址。所有资源都共享统一的界面，以便在客户端和服务器之间传输状态。 </p>  <p>对
事物使用一致的命名规则（naming
scheme）最主要的好处就是你不需要提出自己的规则——而是依靠某个已被定义，在全球范围内，能被绝大多数人所理解的规则。比如，如果你的应用中包含
一个对顾客的抽象，那么我可以相当肯定，用户会希望将一个指向某个顾客的链接，能通过电子邮件发送到同事那里，或者加入到浏览器的书签中，甚至写到纸上。
更透彻地讲：如果在一个类似于Amazon.com的在线商城中，没有用唯一的ID（一个URI）标识它的每一件商品，可想而知这将是多么可怕的业务决
策。</p>  <p>当面对这个原则时，许多人惊讶于这是否意味着需要直接向外界暴露数据库记录（或者数据库记录ID）——自从多年以来面向对象的实践
告诫我们，要将持久化的信息作为实现细节隐藏起来之后，哪怕是刚有点想法都常会使人惊恐。但是这条原则与隐藏实现细节两者之间并没有任何冲突：通常，值得
被URI标识的事物——资源——要比数据库记录抽象的多。例如，一个定单资源可以由定单项、地址以及许多其它方面（可能不希望作为单独标识的资源暴露出
来）组成。标识所有值得标识的事物，领会这个观念可以进一步引导你创造出在传统的应用程序设计中不常见的资源：一个流程或者流程步骤、一次销售、一次谈
判、一份报价请求——这都是应该被标识的事物的示例。同样，这也会导致创建比非RESTful设计更多的持久化实体。 </p>  <p>下面是一些你可能想到的URI的例子： </p>  <p><a href="http://example.com/customers/1234" target="_blank" >http://example.com/customers/1234</a>     <br><a href="http://example.com/orders/2007/10/776654" target="_blank" >http://example.com/orders/2007/10/776654</a>     <br><a href="http://example.com/products/4554" target="_blank" >http://example.com/products/4554</a>     <br><a href="http://example.com/processes/salary-increase-234" target="_blank" >http://example.com/processes/salary-increase-234</a> </p>    <p><strong>通过通用的连接器接口（generic connector interface）对资源进行操作； </strong></p>  <p>对资源的操作包括获取、创建、修改和删除资源，这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。</p>  <p>REST
软件架构遵循了CRUD原则，该原则告诉我们对于资源（包括网络资源）只需要四种行为：创建（Create）、获取（Read）、更新（Update）和
销毁（DELETE）就可以完成对其操作和处理了。其实世界万物都是遵循这一规律：生、变、见、灭。所以计算机世界也不例外。这个原则是源自于我们对于数
据库表的数据操作：insert（生）、select（见）、update（变）和delete（灭），所以有时候CRUD也写作为RUDI，其中的I就
是insert。这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。 </p>    <p><strong>对资源的各种操作不会改变资源标识符； </strong></p>  <p>资源一旦产生，就不应该随便更改标识符，一些网站经常变化自己帖子的地址，这显然是反面的做法。</p>    <p><strong>所有的操作都是无状态的（stateless）。</strong></p>  <p>客户端和服务器之间的交互在请求之间是无状态的。</p>  <p>从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。 </p>  <p>RESTful 应用程序是无状态的。这意味着在 REST 应用程序中，服务器上没有存储任何会话状态。满足请求所需要的所有信息都携带在请求消息本身之中。因此在服务显式地允许的情况下，客户端可以缓存资源的表示形式，从而显著改进应用程序的性能。 </p>  <p>REST对于连接的无状态性实际上要求每次经过无状态的连接协议传送的信息必须包含应用中所有的状态信息。</p>    <p><strong>参考资料：</strong></p>  <p>REST - 维基百科，自由的百科全书    <br><a href="http://zh.wikipedia.org/wiki/REST" target="_blank" >http://zh.wikipedia.org/wiki/REST</a>     <br>REST     <br><a href="http://www.hudong.com/wiki/rest" target="_blank" >http://www.hudong.com/wiki/rest</a></p>  <p>理解REST软件架构    <br><a href="http://www.infoq.com/cn/articles/rest-architecure" target="_blank" >http://www.infoq.com/cn/articles/rest-architecure</a></p>  <p>深入浅出REST    <br><a href="http://www.infoq.com/cn/articles/rest-introduction" target="_blank" >http://www.infoq.com/cn/articles/rest-introduction</a></p>  <p>Ajax/REST 架构风格对于融入式 Web 应用程序的优点    <br><a href="http://www.ibm.com/developerworks/cn/web/wa-ajaxarch/" target="_blank" >http://www.ibm.com/developerworks/cn/web/wa-ajaxarch/</a></p>  <p>Web Service实践之REST vs RPC    <br><a href="http://www.cnblogs.com/mindsbook/archive/2009/11/17/web_service_RESTvsRPC.html" target="_blank" >http://www.cnblogs.com/mindsbook/archive/2009/11/17/web_service_RESTvsRPC.html</a></p>  <p>REST 与 Web 开发    <br><a href="http://www.ibm.com/developerworks/cn/web/lp/restandweb/" target="_blank" >http://www.ibm.com/developerworks/cn/web/lp/restandweb/</a></p>  <p>基于REST架构的Web Service设计    <br><a href="http://www.williamlong.info/archives/1728.html" target="_blank" >http://www.williamlong.info/archives/1728.html</a></p>