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

Posted 2023-05-05

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了RESTful 架构（表现层状态转移）相关的知识，希望对你有一定的参考价值。

参考技术A 概念是 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 的角度去设计。这样只要整个流程不变，局部的数据变化，只需要修改后端的相关配置即可，这样业务可以很大程度的配置化。