REST架构风格

这里是修真院前端小课堂，每篇分享文从

【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】

八个方面深度解析前端知识/技能，本篇分享的是：

【 REST架构风格】

参考：
知乎
理解本真的REST架构风格
REST架构风格最重要的架构约束有6个：

1. 客户-服务器（Client-Server）：通信只能由客户端单方面发起，表现为请求-响应的形式。

• 无状态（Stateless）：通信的会话状态（Session State）应该全部由客户端负责维护。
• 缓存（Cache）：响应内容可以在通信链的某处被缓存，以改善网络效率。
• 统一接口（Uniform Interface）：通信链的组件之间通过统一的接口相互通信，以提高交互的可见性。
• (不懂..)分层系统（Layered System）：通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。
• (不懂..)按需代码（Code-On-Demand，可选）：支持通过下载并执行一些代码（例如Java Applet、Flash或JavaScript），对客户端的功能进行扩展。

REST的五个关键词：

• 资源（Resource）
• 资源的表述（Representation）
• 状态转移（State Transfer）
• 统一接口（Uniform Interface）
• 超文本驱动（Hypertext Driven）

例如我订阅了一个人的博客，想要获取他发表的所有文章（这里『他发表的所有文章』就是一个资源Resource）。于是我就向他的服务发出请求，说『我要获取你发表的所有文章，最好是atom格式的』，这时候服务器向你返回了atom格式的文章列表第一页（这里『atom格式的文章列表』就是资源的表述Representation）。你看到了第一页的页尾，想要看第二页，这时候有趣的事情就来了。如果服务器记录了应用的状态（stateful），那么你只要向服务询问『我要看下一页』，那么服务器自然就会返回第二页。类似的，如果你当前在第二页，想服务器请求『我要看下一页』，那就会得到第三页。但是REST的服务器恰恰是无状态的（stateless），服务器并没有保持你当前处于第几页，也就无法响应『下一页』这种具有状态性质的请求。因此客户端需要去维护当前应用的状态（application state），也就是『如何获取下一页资源』。当然，『下一页资源』的业务逻辑必然是由服务端来提供。服务器在文章列表的atom表征中加入一个URI超链接（hyper link），指向下一页文章列表对应的资源。客户端就可以使用统一接口（Uniform Interface）的方式，从这个URI中获取到他想要的下一页文章列表资源。服务器把『能够进入下一页』这个状态以atom表征形式传输（Transfer）给客户端就是** 状态转移（REpresentational State Transfer）**这个概念。

总结一下，就是：服务器生成包含状态转移的表述数据，用来响应客户端对于一个资源的请求；
客户端借助这份表述数据，记录了当前的应用状态以及对应可转移状态的方式。

当然，为了要实现这一系列的功能，一个不可或缺的东西就是超文本（hypertext）或者说超媒体类型（hypermedia type）。这绝对不是一个简简单单的媒体类型（例如，JSON属性列表）可以做到的。

什么是统一接口？

REST要求，必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。以HTTP/1.1协议为例，HTTP/1.1协议定义了一个操作资源的统一接口，主要包括以下内容：

• 7个HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS
• HTTP头信息（可自定义）
• HTTP响应状态代码（可自定义）
• 一套标准的内容协商机制
• 一套标准的缓存机制
• 一套标准的客户端身份认证机制

REST还要求，对于资源执行的操作，其操作语义必须由HTTP消息体之前的部分完全表达，不能将操作语义封装在HTTP消息体内部。这样做是为了提高交互的可见性，以便于通信链的中间组件实现缓存、安全审计等等功能。

误区

RESTful架构有一些典型的设计误区。
最常见的一种设计错误，就是URI包含动词。因为"资源"表示一种实体，所以应该是名词，URI不应该有动词，动词应该放在HTTP协议中。
举例来说，展示数据，某个URI是/posts/show/1，其中show是动词，这个URI就设计错了，正确的写法应该是/posts/1，然后用GET方法表示show。

如果某些动作是HTTP动词表示不了的，你就应该把动作做成一种资源。比如网上汇款，从账户1向账户2汇款500元，错误的URI是：

post /accounts/1/transfer/500/to/2

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

POST /transaction HTTP/1.1　　
Host: 127.0.0.1　　　　
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