蝈蝈俊.net

-- 用随笔来记录自己的技术感触

随笔 - 655, 评论 - 4839, 引用 - 276

关于

这里是我的技术Blog，下一代CSDN社区Blog在 http://blog.csdn.net/ghj1976/

每月存档

对事物使用一致的命名规则（naming scheme）最主要的好处就是你不需要提出自己的规则——而是依靠某个已被定义，在全球范围内，能被绝大多数人所理解的规则。比如，如果你的应用中包含一个对顾客的抽象，那么我可以相当肯定，用户会希望将一个指向某个顾客的链接，能通过电子邮件发送到同事那里，或者加入到浏览器的书签中，甚至写到纸上。更透彻地讲：如果在一个类似于Amazon.com的在线商城中，没有用唯一的ID（一个URI）标识它的每一件商品，可想而知这将是多么可怕的业务决策。

当面对这个原则时，许多人惊讶于这是否意味着需要直接向外界暴露数据库记录（或者数据库记录ID）——自从多年以来面向对象的实践告诫我们，要将持久化的信息作为实现细节隐藏起来之后，哪怕是刚有点想法都常会使人惊恐。但是这条原则与隐藏实现细节两者之间并没有任何冲突：通常，值得被URI标识的事物——资源——要比数据库记录抽象的多。例如，一个定单资源可以由定单项、地址以及许多其它方面（可能不希望作为单独标识的资源暴露出来）组成。标识所有值得标识的事物，领会这个观念可以进一步引导你创造出在传统的应用程序设计中不常见的资源：一个流程或者流程步骤、一次销售、一次谈判、一份报价请求——这都是应该被标识的事物的示例。同样，这也会导致创建比非RESTful设计更多的持久化实体。

下面是一些你可能想到的URI的例子：

http://example.com/customers/1234
http://example.com/orders/2007/10/776654
http://example.com/products/4554
http://example.com/processes/salary-increase-234

通过通用的连接器接口（generic connector interface）对资源进行操作；

对资源的操作包括获取、创建、修改和删除资源，这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。

REST软件架构遵循了CRUD原则，该原则告诉我们对于资源（包括网络资源）只需要四种行为：创建（Create）、获取（Read）、更新（Update）和销毁（DELETE）就可以完成对其操作和处理了。其实世界万物都是遵循这一规律：生、变、见、灭。所以计算机世界也不例外。这个原则是源自于我们对于数据库表的数据操作：insert（生）、select（见）、update（变）和delete（灭），所以有时候CRUD也写作为RUDI，其中的I就是insert。这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。

对资源的各种操作不会改变资源标识符；

资源一旦产生，就不应该随便更改标识符，一些网站经常变化自己帖子的地址，这显然是反面的做法。

所有的操作都是无状态的（stateless）。

客户端和服务器之间的交互在请求之间是无状态的。

从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。

RESTful 应用程序是无状态的。这意味着在 REST 应用程序中，服务器上没有存储任何会话状态。满足请求所需要的所有信息都携带在请求消息本身之中。因此在服务显式地允许的情况下，客户端可以缓存资源的表示形式，从而显著改进应用程序的性能。

REST对于连接的无状态性实际上要求每次经过无状态的连接协议传送的信息必须包含应用中所有的状态信息。

参考资料：

REST - 维基百科，自由的百科全书
http://zh.wikipedia.org/wiki/REST
REST
http://www.hudong.com/wiki/rest

理解REST软件架构
http://www.infoq.com/cn/articles/rest-architecure

深入浅出REST
http://www.infoq.com/cn/articles/rest-introduction

Ajax/REST 架构风格对于融入式 Web 应用程序的优点
http://www.ibm.com/developerworks/cn/web/wa-ajaxarch/