REST Service 的最佳实践，第 1 部分 重新解析 REST Service-2

look_w

REST over HTTPREST 风格的架构也并不强调和协议的绑定。HTTP 是 WWW 网上广泛使用的并且被证明是有效的通信协议，所以现在 RESTful 服务基本也是基于 HTTP 协议的。资源是由 URI 来指定。
对资源的操作包括获取、创建、修改和删除资源，这些操作正好对应 HTTP 协议提供的 GET、POST、PUT 和 DELETE 方法。通过操作资源的 representation 来操作资源。资源的 representation 可以是 XML 也可以是 HTML，取决于读者是机器还是人，是消费 web 服务的客户软件还是 web 浏览器。当然也可以是任何其他的格式。清单 5 和清单 6 给出了 REST over HTTP 的 request 和 response 的示例。
清单 5. A REST Request over HTTP 示例

1 2	GET /books/123456/xml HTTP/1.1 Host: example.com

清单 6. A REST Response over HTTP 示例

1 2 3 4 5 6 7 8 9 10 11 12 13

HTTP/1.1 200 OK Date: Fri, 10 Sept 2010 17:15:33 GMT Last-Modified: Fri, 10 Sept 2010 17:15:33 GMT ETag: "2b3f6-a4-5b572640" Accept-Ranges: updated Content-Type: text/xml; charset="utf-8" <book category="CHILDREN">     <title lang="en">Harry Potter</title>     <author>J K. Rowling</author>     <year>2005</year>     <price>24.99</price> </book>

从清单 5 和清单 6 种，可以清楚的看到，REST 在最大程度上充分利用了 HTTP，没有增加额外的词汇和约定。
通过前面的分析和比较，我们可以清楚地看到，REST 风格的 web 服务与 SOAP RPC 和 XML RPC 风格的 web 服务相比，http request 更简单，response 的语意更清楚。而且客户端不需要知道那么多关于应用的细节，比如 method name，method 调用的参数等等。
简言之，目前在三种主流的 Web 服务实现方案中，因为 REST 模式的 Web 服务与复杂的 SOAP 和 XML-RPC 对比来讲明显的更加简洁，越来越多的 web 服务开始采用 REST 风格设计和实现。例如，Amazon.com 提供接近 REST 风格的 Web 服务进行图书查找；雅虎提供的 Web 服务也是 REST 风格的。
REST 风格的 web 服务已被广泛的接受和使用，但是在使用的过程中，我们发现其实有很多号称 RESTful 的 web 服务并不是 Roy 定义的 REST 服务，或者违背了其中的一些约束。像 Amazon 和 Flickr 的 web 服务。接下来，我们首先结合实际经验，重新解读 REST 架构风格中的核心概念，帮助读者准确的掌握 REST 架构，最后给出一个完全符合 REST 风格架构的 web 服务定义的例子。
REST 核心概念解读Representational State Transfer在理解 REST 相关的核心概念之前，我们来看看“REST”本身应该怎么理解。“Representational State Transfer”是一个不完整的句子，“Representational”代表的是什么的“表示”?“State”又指的是什么的状态 ?“Transfer”的又是什么？如果我们要把它补全该如何呢？根据 Roy 的论文和我们的实践，应该是“Application States Transfer among the resource ’ s representation”。这里的“State”指的是“应用”的“状态”，这个“状态”是用“资源的表示”来代表的，用户可以在“状态”之间“跳转”。
REST 架构风格定义的约束REST 是一种架构的风格，它是对分布式 hypermidea 系统的架构元素的抽象，提供了一些核心的概念和指导思想。这种架构风格是“客户端 - 服务器”架构风格的一种，也就是说“客户端”发起“请求”，“服务器”处理“请求”并返回相应的结果。REST 的贡献是规定了一系列的方法论，在“请求”方面，规定“客户端”怎么发起“请求”，发的是什么样的“请求”，以什么协议发“请求”；在处理方面，规定“服务器”怎么响应“请求”，返回什么样的“响应”，系统后续应该怎么“跳转”等等。让我们再回顾 Roy 定义的这些约束。
“无状态”（Stateless）
“客户端”和“服务器端”的交互是“无状态”的，也就是说“请求”之间是相互隔离的。“服务器端”不保存“客户端”的应用上下文（context），每个从“客户端”来的“请求”都必须包括所有的必要的信息让“服务器端”能够完全理解“请求”并处理。“客户端”存了很多“会话”的信息。让我们以搜索引擎为例来看看“有状态”和“无状态”的区别。图 1 和图 2 分别给出了两个搜索引擎的“有状态”和“无状态”的交互示例。
图 1. 无状态的搜索引擎的交互示例图 1 所示是无状态的搜索引擎的请求（request）和响应（response）的实例。可以清楚地看出，每个 request 和 response 都是互相独立的，相互之间没有数据的依赖。每个 request 包含服务器端响应这个 request 所需要的所有信息。 以“搜索 SOAP”为例，用户首先发了 request http://www.google.com/search?q=SOAP，并且得到了搜索结果，其中包含了 10 个最相关的搜索结果。这个交互过程就结束了，服务器端没有保存任何和这个请求相关的信息。但是在这个返回的状态中，服务器端把下一步的可能的状态嵌在其中了。比如用户如果在这些结果没有找到自己想要的结果，他可以翻页，翻到第二页。第二页是另一个状态，这时用户点击了第二页，然后客户端又发了一个 request http://www.google.com/search?q=SOAP&start=10，这个 request 了包含了所有的上下文，也就是“按关键字 SOAP 搜索并且以第 10 个搜索结果开始返回”。也就是说，服务器把当前的状态隐含中结果中返回，客户端保存下这些隐含的状态，而不是保存在服务器端。客户端可以根据服务器端返回来的状态构建下一个状态的请求。
“无状态”的好处是每个状态都有一个对应的 URI，这些 URI 可以 bookmark，可以使得用户方便的在浏览器中前进后退，可以在用户希望的任何时候访问任意多次。
图 2. 有状态的搜索引擎的交互示例图 2 是有状态的搜索引擎的 request 和 response 的交互示例。可以看出，request 之间的时序依赖性。以“搜索 SOAP”为例，用户在看 1~10 个搜索结果并想看 11~20 个结果，客户端只需要发一个“start=10”的请求而是发“/search?q=SOAP&start=10”的请求，也就是客户端不用重复前面的 request 的上下文。这使得 HTTP request 相对简单了很多。但是他使得 HTTP protocol 变得复杂。服务器端和客户端需要同步会话的状态，在可靠网络上，这是一个复杂的任务。
“无状态”带来了一些性能的提升。在“visibility”方面，对于监控系统而言，它不用去关心跨请求的数据对当前请求的影响，所以“visibility”有所提升。在“reliability”方面，由于“客户端”保存了很多“会话”数据，因此减少了部分“服务器”端的故障或者网络故障对应用的影响，因此对于用户来说，“reliability”有所提升。最值得一提的是“scalability”，由于“服务器”端能够独立的响应每个 request，而不用依赖会话历史，因此少了很多“资源”的管理和同步，使得多个服务器可以同时服务不同的用户的请求，获得很好的自由扩展功能。
当然，事务都有两面性，“无状态”带来的不足之处包括可能的网络性能的降低，因为“服务器”会发很多重复的数据到不同的“客户端”，使得“客户端”保存所有的会话信息；这也导致了另一个问题，就是“服务器”将失去对应用的一致行为的一部分控制权，而且还对“客户端”的实现产生依赖。