REST构架是什么

REST(RepresentationalState Transfer)是Roy Fielding在其博士论文中提出的一个描述互联系统架构风格的名词，Roy Fielding同时也是HTTP协议规范的主要作者之一。设计REST的动机在于捕捉促使Web成功的各种特征，这些特征也将引导Web的演进。为何称为Representational State Transfer？Web由各种资源组成，一个资源可以包含任何用户感兴趣的东西，例如波音公司定义了Boeing787资源，用户可以通过如下URL访问该资源：
http://www.boeing.com/commercial/787family/index.html
浏览器中将展示出该资源的一种表现方式，或者一种表现状态。如果用户在该页面(index.html)中遍历其他链接，则将访问其他资源，因而也将有其他表现状态展示出来。这意味着客户端应用程序随着每个资源表现状态的不同而发生变化（转移），也即所谓Representational State Transfer。

以下是Roy Fielding自己对REST的解释：

“Representational State Transfer is intended to evoke an image of how awell-designed Web application behaves: a network of web pages (a virtualstate-machine), where the user progresses through an application by selectinglinks (state transitions), resulting in the next page (representing the nextstate of the application) being transferred to the user and rendered for theiruse.”
（参见： http://roy.gbiv.com/pubs/dissertation/evaluation.htm）


REST不是一个标准，W3C并未推出任何关于REST的规范，IBM和微软也没有提供任何REST的SDK。为何？因为REST只是一种体系架构的风格，我们可以理解REST，以REST风格设计Web Service，却不能将之封装为一个产品。与之类似的是我们常说的C/S或者B/S架构，这个世界上还没有C/S或B/S的标准。

尽管REST不是标准，它却利用了如下标准：
* HTTP
* URL
* XML/HTML/GIF/JPEG等 (资源展现)
* text/xml, text/html, image/gif, image/jpeg等 (MIME类型)

事实上，Web就是一个经典的REST系统。REST关心的是Web的宏观布局，而非具体的实现技术（例如采用servlet实现一个Web Service）。

我们接下来考察一个以REST风格实现的Web Service，且称之为元件仓库Web Service。元件仓库可以对外发布一些服务，从而客户能够：
*获得一份元件清单。
*获得某个特定元件的详细信息
*提交一个采购订单(PO)

获取元件清单
这个服务利用一个指向元件清单资源的URL，例如 http://www.parts-depot.com/parts，注意web service如何生成清单的过程对于客户是完全透明的。所有客户只知道上述URL，并得到一个元件清单文档。因此，元件仓库可以在不影响客户的情况下自由修改具体的底层实现。这就是所谓松耦合。假设客户接收到的元件清单文档如下：

<?xml version="1.0"?>
<p:Parts xmlns:p=" http://www.parts-depot.com"
xmlns:xlink=" http://www.w3.org/1999/xlink">
<Part id="00345" xlink:href=" http://www.parts-depot.com/parts/00345"/>
<Part id="00346" xlink:href=" http://www.parts-depot.com/parts/00346"/>
<Part id="00347" xlink:href=" http://www.parts-depot.com/parts/00347"/>
<Part id="00348" xlink:href=" http://www.parts-depot.com/parts/00348"/>
</p:Parts>

这个清单中包含了指向元件详细信息的链接。这是REST的关键特征之一。客户通过检查选取其中的一个链接，便从一个状态转移到下一个状态。

获取元件详细信息
这个服务利用一个指向元件信息资源的URL，例如客户可以通过 http://www.parts-depot.com/parts/00345请求查看00345号元件的信息。假设客户接收到的元件详细信息文档如下：

<?xml version="1.0"?>
<p:Part xmlns:p=" http://www.parts-depot.com"
xmlns:xlink=" http://www.w3.org/1999/xlink">
<Part-ID>00345</Part-ID>
<Name>MAX485CPA</Name>
<Description>美信公司的RS485通讯芯片，民品级</Description>
<Specification xlink:href=" http://www.parts-depot.com/parts/00345/specification"/>
<UnitCost currency="RMB">10.1</UnitCost>
<Quantity>10</Quantity>
</p:Part>

这份文档中又包含了指向元件详细技术参数的链接。

提交PO
这个服务利用一个指向PO提交的URL 。客户依照元件仓库预先定义的PO格式创建一个PO实例文档，这个格式可以通过WSDL公开出来。客户将PO.xml作为HTTP POST承载的内容提交上来。PO服务响应此PO提交请求，从而客户可以随时检索、更新、编辑这个PO。PO于是成为客户端与服务器端共享的一段信息。共享信息(PO)由服务器端指定的URL访问，并暴露为一个Web Service。

一个资源是一个概念实体。一个展示(representation)是该资源的具体表达。形如 http://www.parts-depot.com/parts/00345的URL是一个逻辑URL而非物理URL，因此也不必一定是静态HTML页面。事实上，如果有上百万个元件，静态HTML页面方式的表达未免过于笨重，采用servlet、ASP之类技术实现元件数据库的查询更加合理。

作为一种风格，上述URL并未揭示任何与实现技术相关的信息，我们可以从容地更改具体的实现，而不必修改URL。

综上所述，我们可以看出REST风格的Web Service的特点：
1. Client-Server：采用基于pull的交互风格，将客户端与服务器端分开，将用户界面与数据存储分开。
2. 无状态：每一个从客户端向服务器端发出的请求都必须包含所有必要的信息，以使服务器能理解客户的请求，而无须利用服务器端预存的环境信息
3. 缓存：为了改进网络效率，来自服务器端的响应必须能够被标记为是否可以缓存
4. 统一界面：所有的资源都是经由通用的界面访问，例如HTTP GET, POST, PUT, DELETE)。
5. 命名资源：系统由一系列以URL命名的资源组成。
6. 资源互联：从而客户可以通过URL的链接从一个状态转移到另一个状态。
7. 分层组件：在客户与资源之间可以加入proxy server、 cache server、 gateways等等中间件，从而满足性能、安全性等非功能需求。

在设计REST风格的Web Service时，需要遵循以下原则：
1. 创建REST风格Web Service的关键是识别出所有可能暴露为服务的概念实体，例如前面提到的元件清单、元件详细信息、以及PO。
2. 为每个资源定义一个URL。资源应该是名词，而非动词，例如不要使用如下风格的URL： http://www.parts-depot.com/parts/getPart?id=00345
而是使用：
http://www.parts-depot.com/parts/00345
3. 根据资源的CRUD特性以及是否需要展示给客户，将各种资源进行分类。对于前者，使用HTTP POST, PUT,或 DELETE访问资源，对于后者则通过HTTP GET访问。
4. 所有经由HTTP GET访问的资源都应是没有负面影响的，即，对这些资源的调用不会导致资源的更新。
5. 每一个资源都不应孤立地展示出来，而需要包含能够获取相关资源的链接。
6. 提供指向更详细信息的链接，循序渐进地展示数据，不要试图在一个响应文档中表现所有东西。
7. 使用schema定义响应数据的格式，例如DTD, W3CSchema, RelaxNG, 或者Schematron。对于需要POST或PUT的服务，也同样提供一个统一的响应格式。
8. 利用WSDL文档或者一个简单的HTML页面说明如何访问这些服务。


有关REST的最经典的阐述自然是Fielding的论文：
http://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm