REST架构原则初探

目录

• 什么是RESTful架构？
• REST 架构原则
  • 资源（Resource）
  • 表现层（Representation）
  • 状态转换（State Transfer）
    • 无状态通信原则
• RESUful API 的设计
  • 动词规约：统一资源接口
  • 宾语规约：必须是名词
  • URI 设计技巧
    • 多级 URI 的设计
    • HTTP 的 CRUD 动词无法表述的业务需求
    • 对需要获取不同版本的资源
• 总结

什么是RESTful架构？

RESTful 架构，是目前最流行的一种互联网软件架构。它基于REST原则，结构清晰、符合标准、易于理解、扩展方便，正得到越来越多网站的采用。

在传统上，软件和网络是两个不同的领域，很少有交集；软件开发主要针对单机环境，网络则主要研究系统之间的通信。互联网的兴起，使得这两个领域开始融合，越来越多的人开始意识到，网站即软件，而且是一种新型的软件。

2000年，Roy Thomas Fielding（HTTP 协议的主要设计者、Apache 基金会的第一任主席）在他的博士论文中提出了「REST」这一概念；对于论文的写作目的，他有如下的描述：

   我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。

Fielding将他对互联网软件的架构原则，定名为 REST，即 Representational State Transfer 的缩写。这里对这个词组的翻译是「表现层状态转化」。

如果一个架构符合REST原则，就称它为 RESTful 架构；也就是说，只要我们弄清楚了 Representational State Transfer 这个词组的含义，也就弄明白了 RESTful 架构是怎么一回事。

这里先对 REST 原则进行描述，再对 RESTful API 的设计方法展开讨论。

REST 架构原则

前面提到，REST 其实是「Representational State Transfer」词组的缩写，我们可以从下面三个部分入手，理解这个词组的含义：

资源（Resource）

REST 可译作“表现层状态转换“，其实对主语还进行了一层省略：这里的“表现层”指的就是「资源（Resource）」的「表现层」。

在 REST 架构原则看来，网络上的每个具体信息都是一个实体，也就是资源；资源可以是一个文本、一段文字、一张图片、一种服务，总之就是一个具体的实体。我们用一个 URI （唯一资源标示符）来唯一指向特定的某个资源。在使用时，我们应保证 uri 具有良好的可读性和标示性。

下面给出一个 github 的链接示例：

https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08

上述链接便很清晰明了，标示了 git 上一次特定的 commit 请求。

所谓的“上网”，其实就是与网络上的“资源”进行交互，对“资源”的 uri 进行调用。

表现层（Representation）

上面提到，「Resource」是网络上某种信息的实体，但即使对于同一种资源，我们会希望能够它能以不同的形式呈现在用户面前。而这种将「资源」具体呈现出来的形式，便称为表现层（Representation）。

例如，现有一段文字信息，对于这个「文字资源」，在进行数据传输时我们希望它能够以 JSON 进行传输，而在存储时我们又可能希望它能够以 XML 或是 txt 形式存储在本地。

对于一个资源，我们用一个 URI 来标示它的实体，但 URI 不能标示资源的形式。套用上面的例子，文字资源的 uri 只能让服务器或客户端准确地找到这个资源，但服务器和客户端不知道这个资源是哪种形式的。也就是说，用户真正需要看到的并不仅仅是资源，而是资源的特定 Representation。

很多网站直接在 URL 中直接指定资源的表现形式，例如 CSDN 和博客园，每篇博客的 URL 后都可以看到「.html」的后缀：

https://www.cnblogs.com/bellkosmos/p/5237146.html

严格意义上来说这样的后缀名是不规范的：因为 URI 应该只代表资源的地址，「.html」后缀代表文字信息的格式，属于「表现层」的范畴；一个资源的具体表现形式，应该在 HTTP 请求的头信息中，使用 Accept 和 Content-Type 字段来指定。

下面的 ajax 代码就是一个很好的例子，它通过 Content-Type 字段指定 HTTP 的 body 是一个 JSON 格式、且采用 utf-8 字符集编码的文本信息：

$.ajax({
    type: "POST",
    url: "/users",
    contentType: "application/json;charset=utf-8",
    data:{
        "name": "test",
        "pwd": "123456"
    },
    dataType: "json",
    success:function (message) {
        alert("提交成功"+JSON.stringify(message));
    },
    error:function (message) {
        alert("提交失败"+JSON.stringify(message));
    }
});

状态转换（State Transfer）

了解了「Resource」和「Presentation」后，我们便可以按照自己的需要获取到我们理想状态的数据，但现实生活中，用户访问网站实际上是一个客户端和服务器之间的互动过程，这个过程中双方不断的建立连接进行通信，势必会涉及到数据和状态的变化。

这里涉及到「状态」这个可能引起困惑的名词，我们将其和 REST 原则中的「无状态通信原则」放在一起讨论。

无状态通信原则

首先需要说明的是，这里说的无状态通信原则，并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。同时，互联网的基石，HTTP 协议，也是一个「无状态」协议。

「状态」指的是什么？

实际上，「状态」应该区分为应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。「应用状态」便是用户在客户端进行的种种业务操作，例如对数据的更新操作；而在客户端，当对一个数据进行诸如更新等操作后，我们就可以说「资源状态」发生了改变。

什么是「无状态通信」？

从名字的意义相近，在「无状态通信」中，客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。

• 「无状态」的交互

  这样以来，服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态，并且根据应用状态来令资源状态作出相应的改变。

• 每次请求中包含这次请求所需的所有信息

  这个比较好理解，应为服务端不会保存客户端的状态，所以每次请求对服务端来说都是独立存在的；如果当前请求中的信息不足以让服务端完成这个请求，那么这个请求将无效。

这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。 在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。

当然，我们也有需要违法无状态通信的业务场景，例如「登录」操作，如果是遵循无状态通信，那么用户每次进行业务操作都需要重新进行登录，无疑是非常反人类的体验。在这种类似的场景中，我们可以使用「session」和「cookie」来跟踪和保存会话状态。

看到这里，状态转移应该就很好理解了：在客户端和服务器进行交互时，如果客户端的「应用状态」发生变化（如用户注册一个新账号提交了一个表单数据），程序就需要让服务器的「资源状态」按照客户端要求发生「状态转换」（也就是 CREATE 一个新的账号数据）。而这种转换是建立在表现层之上的，所以是「表现层状态转换」，也就是「REST」。

那么，对「REST」这个词组大家应该有一个大致的了解了，那再看看不难猜到「REST（表现层状态转换）」架构原则是做什么的了：对程序员（针对资源表现层的）程序中编写的状态转换方法作出约束，建立一个大家都应该去遵守的标准。

而在当今的互联网架构下，客户端能用到的手段，只有 HTTP 协议。简单来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

如果在编程中我们能够做到遵循这一原则，假设我们希望对一辆小车的图片进行查询，我们设计的 API 可能是这样的：

[GET] /img/car

如果我们需要希望删除这个图片，我们只需要将「GET」改成使用「DELETE」方法即可，这种 API 将资源定位和资源操作相分离，能够更加简洁直观地展示指令的需求。

更具体的便是 RESTful API 设计考虑的内容了，我们会在后续进行讨论。

RESUful API 的设计

RESTful 的核心思想就是，客户端发出的数据操作指令都是「动词 + 宾语」的结构。比如，GET /articles这个命令，GET是动词，/articles是宾语。按照之前提到的 REST 原则，「动词」便是「状态转换」，「宾语」就是「表现层」，连起来就是「表现层状态转换」，也就是 REST 了。

动词规约：统一资源接口

对于所有的资源，都是使用相同的接口进行访问，动词指的都是固定五种 HTTP 方法，对应数据的 CRUD 操作，这便是 RESTful架构的「统一接口原则」。

• GET：读取（Read）
• POST：新建（Create）
• PUT：更新（Update）
• PATCH：更新（Update），通常是部分更新
• DELETE：删除（Delete）

按照 HTTP 的规范，动词一律采用大写。

宾语规约：必须是名词

宾语就是 API 的 URI，是 HTTP 动词作用的对象。按照 REST 原则，URI 应该只能起到对资源及其表现层进行唯一标示的作用。也就是说，它应该是名词，不能是动词，因此下面 URI 中含有 get、create等动词，都是不符合要求的 URI：

[GET] /getUser/1
[POST] /createUser
[PUT] /updateUser/1
[DELETE] /deleteUser/1

URI 既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用 URI 来表示，那它就不能算是一个资源， 只能算是资源的一些信息而已。

对 RESTful 进行基础的了解后，我们来看看 URI 的一些设计技巧：

URI 设计技巧

多级 URI 的设计

多级 URI 设计这一块网络上有多种说法，这里我认为 github 的规范应该足以作为我们的标准：

• 在页面间进行跳转时，使用「/」来表示资源的层级关系

  例如，我们需要查询「octokit」用户的所有仓库：

  [GET] /octokit
  

  我们会看到如下页面：

  

  我们点击其第一个仓库「rest.js」，这时浏览器进行了页面跳转：

  

  可以看到 github 这里进行使用「/」进行分割 URI，上面页面的 URI 是这样的：

  [GET] /octokit/rest.js
  

• 在当前页面进行过滤时，使用「?」用来过滤资源

  看下面这样一个 github 页面，它是上面仓库的 issue 页面，它的 URI 是/octokit/rest.js/issues：

  

  假设这时我们希望查看所有 「Closed」的 issue，按照前面分级 URI 的思想，很容易写出这样的 URI：

  [GET] /octokit/rest.js/issues/closed
  

  这种 URL 不利于扩展，语义也不明确，往往要想一会，才能明白含义。

  更好的做法是，除了第一级，其他级别都用查询字符串表达：

  [GET] /octokit/rest.js/issues?status=closed
  

  这里用「?」对资源过滤，这种URL通常对应的是一些特定条件的查询结果或算法运算结果。看看 github 中的实现：

  

  可以看到，github 中使用了「?」来进行过滤，为/octokit/rest.js/issues?q=is%3Aissue+is%3Aclosed，只是过滤字段我们前面预估有一些不同。

HTTP 的 CRUD 动词无法表述的业务需求

如果某些动作是 HTTP 动词表示不了的，你就应该把动作做成一种资源。

比如网上汇款，从账户1向账户2汇款500元，错误的URI是：

[POST] /accounts/1/transfer/500/to/2

正确的写法是把动词「transfer」改成名词「transaction」，资源不能是动词，但是可以是一种服务：

[POST] /transaction/from=1&to=2&amount=500.00

对需要获取不同版本的资源

一个常见的设计误区，就是在URI中加入版本号：

http://www.example.com/app/1.0/foo
http://www.example.com/app/1.1/foo
http://www.example.com/app/2.0/foo

因为不同的版本，可以理解成同一种资源的不同表现形式，所以应该采用同一个URI。版本号可以在HTTP请求头信息的「Accept」字段中进行区分（参见Versioning REST Services）：

Accept: vnd.example-com.foo+json;version=1.0
Accept: vnd.example-com.foo+json;version=1.1
Accept: vnd.example-com.foo+json;version=2.0

总结

最后，我们再总结一下 RESTful 架构：

1. 每一个 URI 代表一种资源；
2. 客户端和服务器之间，传递这种资源的某种表现层；
3. 客户端通过五个 HTTP 动词，对服务器端资源进行操作，实现「表现层状态转化」。

---

参考链接：

理解RESTful架构

RESTful API 最佳实践

RESTful 架构详解

http协议无状态中的 "状态" 到底指的是什么？！