理解由来
概念是 Roy Thomas Fielding在他2000年的博士论文中提出的。他参与制定了 HTTP 1.0 和 HTTP 1.1 协议。
他希望能基于网络现有的协议基础上创建一个功能强大，性能游戏，适宜通信的架构。
概念
客户端 - 服务器分离（Client - Server）
如含义一样，将从逻辑上将业务实现拆分为客户端与服务端实现。
通过分离设计，能简化两边的设计复杂度，提高其可扩展性。
资源（Resources）
资源是 RESTful 的主体，主要指代互联网上的一个实体，可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。资源通过 URI 来唯一标识。
表现层（Representation）
资源的信息载体形式，叫做表现层。他可以是文本、XML、JSON 或者是一个二进制文件。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。
状态转化（State Transfer）
互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。
在 HTTP 中，我们一般通过四种 HTTP 动词（verb）来对应资源的变化：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
相应的状态的交互应当是无状态的（ServerLess）这是 HTTP 的特性所决定的，要求每次请求包含服务器需要的所有信息，这样可以很好的确保每一次变化的可预测性，进而提高可靠性，也能增进可扩展性。
综述
综合上面的解释，我们总结一下什么是RESTful架构：
（1）每一个URI代表一种资源；
（2）客户端和服务器之间，传递这种资源的某种表现层；
（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。
HTTP 与 RESTful
HTTP 请求是互联网架构中重要的一环，其在 TCP 连接的基础上，实现了语义化，缓存机制，无状态等等特性。在互联网上也有不错的性能，REST 常常会基于 HTTP 协议的基础上实现其核心概念。
论文中对 HTTP 与 REST 相适宜的论述提及了几点：
- 可扩展性：主要是协议的 method，返回状态码，协议向下兼容性
- 自我信息描述：主要是从 URI 能准确定义资源，Content-type HTTP 头能准确定义表现层，还有相关语义化的 HTTP 头。
- 性能：主要从 HTTP 高于网络层，在实现上能复用 TCP 连接，减少 TCP 建立与销毁的时间成本。还有就是 HTTP 其容易缓存的特性。
这里是论文中对 HTTP Code 来表现业务相应状态的相关表述：
Matin Fowler 关于 RESTful 的成熟度模型
原文： https://martinfowler.com/articles/richardsonMaturityModel.html
他讲这个模型层次分为四级，大概如下所示：
Level 0
利用 HTTP 协议做数据交换，所有的参数描述通过 url 或者 POST body 形式通知服务器，返回相应的数据，此级别通常都是基于 。实质上就是基于 HTTP 的 RPC（远程过程调用），具体交付的细节完全由相关规范或团队内部约定解决。
根据理解设计了一份请求交互：
POST /apiService
{
"action": "bookMeeting",
"roomID": "Roma",
"guestIDs": ["Roy", "Tom"],
"from": "201805221400",
"to": "201805221500"
}
------- Response
{
"status": "succuess",
"guestIDs": ["Roy", "Tom"],
"meetingID": "201805221400-201805221500-Roma"
}
Level 1
将 API 按照 RESTful 中资源的方式进行划分，初步有了自我描述（self description）的特性了，客户端可以对相关的资源进行更加细致的操作。
根据理解设计了一份请求交互：
POST /apiService/room/Roma
{
"action": "bookMeeting",
"guestIDs": ["Roy", "Tom"],
"from": "201805221400",
"to": "201805221500"
}
------- Response
{
"status": "succuess",
"guestIDs": ["Roy", "Tom"],
"meetingID": "201805221400-201805221500-Roma"
}
Level 2
这个级别有更加进一步的利用了 HTTP 的特性，增加了对 HTTP verb （比如 GET 表示查询、POST 表示创建、PUT 表示修改、DELETE 表示 等等）的运用，并且运用原有的 HTTP response status 来表征业务上请求的成功与失败，一般项目常见的 RESTful 运用基本都接近这个级别。
这个请求基本就和我们平时使用的 RESTful api 很接近了：
POST /apiService/room/Roma
{
"guestIDs": ["Roy", "Tom"],
"from": "201805221400",
"to": "201805221500"
}
------- Response
status: 201
{
"guestIDs": ["Roy", "Tom"],
"meetingID": "201805221400-201805221500-Roma"
}
Level 3
这个基本也称作 HATEOAS (Hypertext As The Engine Of Application State)，这个级别是 RESTful 最复杂的实现，这个级别最理想的情况是，不需要特别复杂 API 文档进行描述的，这里的 API 设计最大化的实现了 RESTful 的自我描述特性。这种方案虽然引入很大的复杂性，但是最大限度的将 API 设计变得配置化了，所有 API 设计将会基于更加抽象的工作流设计了，稍后再做解释：
本阶段的相关请求模型大概是这样的：
GET /apiService/room
---- Response
{
roomList: [
{
meetingID: "Roma",
__link: [
{
method: "POST",
url: "/apiService/room/Roma",
parameters: {
guestIDs: "[guestID]",
from: "timestamp",
to: "timestamp"
}
}
]
},
...
]
}
------------
POST /apiService/room/Roma
{
"guestIDs": ["Roy", "Tom"],
"from": "201805221400",
"to": "201805221500"
}
------- Response
status: 201
{
"meetingID": "201805221400-201805221500-Roma"
_links: [
{
url: '/apiService/meeting/201805221400-201805221500-Roma',
methos: 'GET'
},
...
]
}
可以看出，从查询到最终结果，都是由第一个 api 的返回的资源列表和操作项，引导向后面的操作，这样，后端在设计 API 的时候，需要考虑从一条业务 workflow 的角度去设计。这样只要整个流程不变，局部的数据变化，只需要修改后端的相关配置即可，这样业务可以很大程度的配置化。
