Skip to content

RESTful 架构¶

REST 全称是 Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。

REST 指的是一组架构约束条件和原则。如果一个架构符合 REST 的约束条件和原则，我们就称它为 RESTful 架构。

REST 本身并没有创造新的技术、组件或服务，而隐藏在 RESTful 背后的理念就是使用 Web 的现有特征和能力，更好地使用现有 Web 标准中的一些准则和约束。

虽然 REST 本身受 Web 技术的影响很深，但是理论上 REST 架构风格并不是绑定在 HTTP 上，只不过目前 HTTP 是唯一与 REST 相关的实例。

RESTful 架构与传统的 RPC、SOAP 等方式在理念上有很大的不同。

下面结合 REST 原则，围绕资源展开讨论，从资源的定义、获取、表述、关联、状态变迁等角度，列举一些关键概念并加以解释。

资源与 URI
统一资源接口
资源的表述
资源的链接
状态的转移

资源与 URI¶

任何事物，只要有被引用到的必要，它就是一个资源。要让一个资源可以被识别，需要有个唯一标识，在 Web 中这个唯一标识就是 URI (Uniform Resource Identifier)。

使用_或 - 来让 URI 可读性更好
使用 / 来表示资源的层级关系
使用？用来过滤资源
, 或；可以用来表示同级资源的关系

统一资源接口¶

RESTful 架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。统一资源接口要求使用标准的 HTTP 方法对资源进行操作。

如果按照 HTTP 方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性。

GET 和 HEAD 请求都是安全的，无论请求多少次，都不会改变服务器状态。
而 GET、HEAD、PUT 和 DELETE 请求都是幂等的，无论对资源操作多少次，结果总是一样的，后面的请求并不会产生比第一次更多的影响。
POST 和 PUT 在创建资源的区别在于，所创建的资源的名称 (URI) 是否由客户端决定。
一些比较古老的基于浏览器的客户端，只能支持 GET 和 POST 两种方法。
统一接口不意味着不能扩展带特殊语义的方法，不过服务端需要考虑客户端是否能够支持的问题。

GET¶

安全且幂等
获取表示
变更时获取表示（缓存）
200（OK） - 表示已在响应中发出
204（无内容） - 资源有空表示
301（Moved Permanently） - 资源的 URI 已被更新
303（See Other） - 其他（如，负载均衡）
304（not modified）- 资源未更改（缓存）
400 （bad request）- 指代坏请求（如，参数错误）
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务端当前无法处理请求

POST¶

不安全且不幂等
使用服务端管理的（自动产生）的实例号创建资源
创建子资源
部分更新资源
如果没有被修改，则不过更新资源（乐观锁）
200（OK）- 如果现有资源已被更改
201（created）- 如果新资源被创建
202（accepted）- 已接受处理请求但尚未完成（异步处理）
301（Moved Permanently）- 资源的 URI 被更新
303（See Other）- 其他（如，负载均衡）
400（bad request）- 指代坏请求
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示
409 （conflict）- 通用冲突
412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务当前无法处理请求

PUT¶

不安全但幂等
用客户端管理的实例号创建一个资源
通过替换的方式更新资源
如果未被修改，则更新资源（乐观锁）
200 （OK）- 如果已存在资源被更改
201 （created）- 如果新资源被创建
301（Moved Permanently）- 资源的 URI 已更改
303 （See Other）- 其他（如，负载均衡）
400 （bad request）- 指代坏请求
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示
409 （conflict）- 通用冲突
412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务当前无法处理请求

DELETE¶

不安全但幂等
删除资源
200 （OK）- 资源已被删除
301 （Moved Permanently）- 资源的 URI 已更改
303 （See Other）- 其他，如负载均衡
400 （bad request）- 指代坏请求
404 （not found）- 资源不存在
409 （conflict）- 通用冲突
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务端当前无法处理请求

资源的表述¶

通过 HTTP 内容协商，客户端可以通过 Accept 头请求一种特定格式的表述，服务端则通过 Content-Type 告诉客户端资源的表述形式。

使用 URI 后缀来区分表述格式¶

像 rails 框架，就支持使用 /users.xml 或 /users.json 来区分不同的格式。这样的方式对于客户端来说，无疑是更为直观，但混淆了资源的名称和资源的表述形式。

处理不支持的表述格式¶

当服务器不支持所请求的表述格式，它应该返回一个 HTTP 406 响应，表示拒绝处理该请求。

资源的链接¶

术语：超媒体即应用状态引擎（hypermedia as the engine of application state）

当你浏览 Web 网页时，从一个连接跳到一个页面，再从另一个连接跳到另外一个页面，就是利用了超媒体的概念：把一个个把资源链接起来。要达到这个目的，就要求在表述格式里边加入链接来引导客户端。

应该多花一些时间来给资源的表述提供链接，而不是专注于 "资源的 CRUD"。

状态的转移¶

EST 原则中的无状态通信原则：不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。

应用状态与资源状态¶

状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。
客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。
服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。
无状态通信原则，使得服务端和中介能够理解独立的请求和响应。
在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。
但有时候我们会做出违反无状态通信原则的设计，例如利用 Cookie 跟踪某个服务端会话状态，常见的像 J2EE 里边的 JSESSIONID。

应用状态的转移¶

类似 "下一页" 之类的链接起推进状态的作用 —— 指引你如何从当前状态进入下一个可能的状态。

"会话" 状态不是作为资源状态保存在服务端的，而是被客户端作为应用状态进行跟踪的。
客户端应用状态在服务端提供的超媒体的指引下发生变迁。
服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。