目录
什么是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 架构:
- 每一个 URI 代表一种资源;
- 客户端和服务器之间,传递这种资源的某种表现层;
- 客户端通过五个 HTTP 动词,对服务器端资源进行操作,实现「表现层状态转化」。
参考链接: