起源

REST这个词，是Roy Thomas Fielding在他2000年的博士论文中提出的

Fielding，HTTP协议（1.0版和1.1版）的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席

REST

Fielding将他对互联网软件的架构原则，定名为REST，即Representational State Transfer的缩写
如果一个架构符合REST原则，就称它为RESTful架构

REST的名称”表现层状态转化”中，省略了主语。”表现层”其实指的是”资源”（Resources）的”表现层”。

资源 Resources

所谓”资源”，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在
你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符

表现层 Representation

“资源”是一种信息实体，它可以有多种外在表现形式
我们把”资源”具体呈现出来的形式，叫做它的”表现层”（Representation）

比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现

URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的”.html”后缀名是不必要的，因为这个后缀名表示格式，属于”表现层”范畴，而URI应该只代表”资源”的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对”表现层”的描述

状态转化（State Transfer）

访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化
互联网通信协议HTTP协议，是一个无状态协议
这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生”状态转化”（State Transfer）。而这种转化是建立在表现层之上的，所以就是”表现层状态转化”
客户端用到的手段，只能是HTTP协议
具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源

总结

综合上面的解释，我们总结一下什么是RESTful架构：

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

原则

C-S架构

数据的存储在Server端，Client端只需使用就行。两端彻底分离的好处使client端代码的可移植性变强，Server端的拓展性变强。两端单独开发，互不干扰

无状态

http请求本身就是无状态的，基于C-S架构，客户端的每一次请求带有充分的信息能够让服务端识别
请求所需的一些信息都包含在URL的查询参数、header、div，服务端能够根据请求的各种参数，无需保存客户端的状态，将响应正确返回给客户端。无状态的特征大大提高的服务端的健壮性和可拓展性

当然，这种无状态性的约束也是有缺点的，客户端的每一次请求都必须带上相同重复的信息确定自己的身份和状态，造成传输数据的冗余性，但这种确定对于性能和使用来说，几乎是忽略不计的

统一的接口

REST架构的核心内容，统一的接口对于RESTful服务非常重要。客户端只需要关注实现接口就可以，接口的可读性加强，使用人员方便调用

REST接口约束定义为：资源识别; 请求动作; 响应信息; 它表示通过uri标出你要操作的资源，通过请求动作（http method）标识要执行的操作，通过返回的状态码来表示这次请求的执行结果

一致的数据格式

服务端返回的数据格式要么是XML，要么是Json（获取数据），或者直接返回状态码，一些知名网站的开放平台的操作数据的api，post、put、patch都是返回的一个状态码

如请求一条微博信息，服务端响应信息应该包含这条微博相关的其他URL，客户端可以进一步利用这些URL发起请求获取感兴趣的信息，再如分页可以从第一页的返回数据中获取下一页的URT也是基于这个原理

可缓存

在万维网上，客户端可以缓存页面的响应内容。因此响应都应隐式或显式的定义为可缓存的，若不可缓存则要避免客户端在多次请求后用旧数据或脏数据来响应
管理得当的缓存会部分地或完全地除去客户端和服务端之间的交互，进一步改善性能和延展性

按需编码、可定制代码

服务端可选择临时给客户端下发一些功能代码让客户端来执行，从而定制和扩展客户端的某些功能
比如服务端可以返回一些 Javascript 代码让客户端执行，去实现某些特定的功能。

提示：REST架构中的设计准则中，只有按需编码为可选项。如果某个服务违反了其他任意一项准则，严格意思上不能称之为RESTful风格。

示例

版本控制

如github开放平台的API：http://developer.github.com/v3/
可以发现，一般的项目加版本v1，v2，v3版本号，为的是兼容一些老版本的接口，这个加版本估计只有大公司大项目才会去使用

参数命名规范

query parameter可以采用驼峰命名法，也可以采用下划线命名的方式，后者比前者的识别度要高
其中，做前端开发基本都后后者，而做服务器接口开发基本用前者

url命名规范

API命名应该采用约定俗成的方式，保持简洁明了
在RESTful架构中，每个url代表一种资源，所以url中不能有动词，只能有名词，并且名词中也应该使用复数
实现者应使用相应的Http动词GET、POST、PUT、PATCH、DELETE、HEAD来操作这些资源

统一返回数据格式

对于合法的请求应该返回统一的数据格式，对于返回数据，通常会包含如下字段

• code
  包含一个整数类型的HTTP响应状态码
• status
  包含文本：”success”，”fail”或”error”。
• HTTP状态响应码
  在500-599之间为”fail”，在400-499之间为”error”，其它均为”success”（例如：响应状态码为1XX、2XX和3XX）。这个根据实际情况其实是可要可不要的

常用的设置有：

状态码	信息	请求类型	意义
200	OK	[GET]	服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）。
201	CREATED	[POST/PUT/PATCH]	用户新建或修改数据成功。
202	Accepted	[*]	表示一个请求已经进入后台排队（异步任务）
204	NO CONTENT	[DELETE]	用户删除数据成功。
400	INVALID REQUEST	[POST/PUT/PATCH]	用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。
401	Unauthorized	[*]	表示用户没有权限（令牌、用户名、密码错误）。
403	Forbidden	[*]	表示用户得到授权（与401错误相对），但是访问是被禁止的。
404	NOT FOUND	[*]	用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。
406	Not Acceptable	[GET]	用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。
410	Gone	[GET]	用户请求的资源被永久删除，且不会再得到的。
422	Unprocesable entity	[POST/PUT/PATCH]	当创建一个对象时，发生一个验证错误。
500	INTERNAL SERVER ERROR	[*]	服务器发生错误，用户将无法判断发出的请求是否成功。

• message
  当状态值为”fail”和”error”时有效，用于显示错误信息。参照国际化（il8n）标准，它可以包含信息号或者编码，可以只包含其中一个，或者同时包含并用分隔符隔开
• data
  包含响应的div。当状态值为”fail”或”error”时，data仅包含错误原因或异常名称、或者null也是可以的

---

参考：

• http://www.ruanyifeng.com/blog/2011/09/restful.html
• https://zhuanlan.zhihu.com/p/91240556