RESTful 架构 （表现层状态转移）

概念是 Roy Thomas Fielding在他2000年的博士论文中提出的。他参与制定了 HTTP 1.0 和 HTTP 1.1 协议。

他希望能基于网络现有的协议基础上创建一个功能强大，性能游戏，适宜通信的架构。

如含义一样，将从逻辑上将业务实现拆分为客户端与服务端实现。

通过分离设计，能简化两边的设计复杂度，提高其可扩展性。

资源是 RESTful 的主体，主要指代互联网上的一个实体，可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。资源通过 URI 来唯一标识。

资源的信息载体形式，叫做表现层。他可以是文本、XML、JSON 或者是一个二进制文件。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。

互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。

在 HTTP 中，我们一般通过四种 HTTP 动词（verb）来对应资源的变化：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

相应的状态的交互应当是无状态的（ServerLess）这是 HTTP 的特性所决定的，要求每次请求包含服务器需要的所有信息，这样可以很好的确保每一次变化的可预测性，进而提高可靠性，也能增进可扩展性。

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

（1）每一个URI代表一种资源；

（2）客户端和服务器之间，传递这种资源的某种表现层；

（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

HTTP 请求是互联网架构中重要的一环，其在 TCP 连接的基础上，实现了语义化，缓存机制，无状态等等特性。在互联网上也有不错的性能，REST 常常会基于 HTTP 协议的基础上实现其核心概念。

论文中对 HTTP 与 REST 相适宜的论述提及了几点：

这里是论文中对 HTTP Code 来表现业务相应状态的相关表述：

原文： https://martinfowler.com/articles/richardsonMaturityModel.html

他讲这个模型层次分为四级，大概如下所示：

利用 HTTP 协议做数据交换，所有的参数描述通过 url 或者 POST body 形式通知服务器，返回相应的数据，此级别通常都是基于 。实质上就是基于 HTTP 的 RPC（远程过程调用），具体交付的细节完全由相关规范或团队内部约定解决。

根据理解设计了一份请求交互：

将 API 按照 RESTful 中资源的方式进行划分，初步有了自我描述（self description）的特性了，客户端可以对相关的资源进行更加细致的操作。

根据理解设计了一份请求交互：

这个级别有更加进一步的利用了 HTTP 的特性，增加了对 HTTP verb （比如 GET 表示查询、POST 表示创建、PUT 表示修改、DELETE 表示 等等）的运用，并且运用原有的 HTTP response status 来表征业务上请求的成功与失败，一般项目常见的 RESTful 运用基本都接近这个级别。

这个请求基本就和我们平时使用的 RESTful api 很接近了：

这个基本也称作 HATEOAS (Hypertext As The Engine Of Application State)，这个级别是 RESTful 最复杂的实现，这个级别最理想的情况是，不需要特别复杂 API 文档进行描述的，这里的 API 设计最大化的实现了 RESTful 的自我描述特性。这种方案虽然引入很大的复杂性，但是最大限度的将 API 设计变得配置化了，所有 API 设计将会基于更加抽象的工作流设计了，稍后再做解释：

本阶段的相关请求模型大概是这样的：

可以看出，从查询到最终结果，都是由第一个 api 的返回的资源列表和操作项，引导向后面的操作，这样，后端在设计 API 的时候，需要考虑从一条业务 workflow 的角度去设计。这样只要整个流程不变，局部的数据变化，只需要修改后端的相关配置即可，这样业务可以很大程度的配置化。

先看REST是什么意思，英文Representational state transfer 表述性状态转移 其实就是对 资源 的表述性状态转移。

简单的说：RESTful是一种架构的规范与约束、原则，符合这种规范的架构就是RESTful架构。

资源的地址 在web中就是URL （统一资源标识符）

资源是REST系统的核心概念。 所有的设计都是以资源为中心

结合项目怎么识别资源

1.商品加入购物车 购物车

2.提交订单 订单

3.创建用户 用户

围绕资源进行 添加，获取，修改，删除，以及对符合特定条件的资源进行列表操作 。针对资源设计接口

RESTful 架构的核心规范与约束：统一接口

分为四个子约束：

1.每个资源都拥有一个资源标识，每个资源的资源标识可以用来唯一地标明该资源

2.消息的自描述性

3.资源的自描述性。

4.HATEOAS Hypermedia As The Engine Of Application State(超媒体作为应用状态引擎)

即客户只可以通过服务端所返回各结果中所包含的信息来得到下一步操作所需要的信息，如到底是向哪个URL发送请求等。也就是说，一个典型的REST服务不需要额外的文档标示通过哪些URL访问特定类型的资源，而是通过服务端返回的响应来标示到底能在该资源上执行什么样的操作

目的：实现客户端无需借助任何文档即能调用到所有的服务器资源

三、资源的URL设计

1.通过URL来表示资源

资源分为主资源与子资源

因为主资源是一类独立的资源 所以主资源应直接放在相对路径下：例如

若要表示主资源的实例：如果实例的ID=1，则这样表示： /goods/1

子资源：

一个实例的子资源可能是一个集合也可能是一个单一的子资源

子资源为图片集合：/goods/1/pictures

子资源为商品折扣的单子子资源：/goods/1/discount

2.单数 vs. 复数

获取用户1的信息，哪种方式更符合RESTful?

/api/users/1

/api/user/1

3.相对路径 vs. 请求参数

极光的RESTful API:

获取用户信息 GET /v1/users/{username} 参数放在路径中

VS

获取用户信息 GET /v1/users?username=xxxxx 拼接的方式

获取应用管理员列表 GET /v1/admins?start={start}&count={count} ？后拼接参数的方式：这种方式一般作为过滤资源

4.使用合适的动词 get delete put post

选择请求接口的方式： get delete

PUT 在服务器更新资源（客户端提供改变后的完整资源）。

POST 在服务器新建一个资源

5.使用标准的状态码

GET

hello world!!!

---