RESTful 架构

染墨^O^

已于 2022-03-16 14:19:31 修改

阅读量1k

点赞数

分类专栏： JS基础文章标签： restful 架构 ajax

于 2022-01-03 13:20:50 首次发布

本文链接：https://blog.csdn.net/weixin_46864830/article/details/122286462

版权

JS基础专栏收录该内容

19 篇文章 1 订阅

订阅专栏

RESTful 架构

在上一篇文章中，我为大家介绍了 HTTP 协议。我们知道一个网络通信基于此协议，发送的网络请求叫做 HTTP 请求，返回的响应叫做 HTTP 响应。

本篇文章要介绍的 RESTful 架构就和 HTTP 协议的知识息息相关。

本文主要包含以下知识点：

RESTful 架构概述
RESTful API 设计示例
RESTful 架构优点

RESTful 架构概述

首先，RESTful 是一种 API 的设计规则。

要理解这个东西，我们还是采用老办法“拆词”。

“RESTful” 后面的 “ful” 是一种单词后缀，多加在名词之后表示“充满…的、易于…、可…的、富有…的、具有…的”的意思，是最常用的形容词后缀。

类似的单词有：beautiful 美丽的、useful 有用的、helpful 乐于帮助的、skillful 有技巧的、bagful 一袋之量，满袋、basketful一满篮，一满筐、capful一帽子、carful 一车之量、cupful 一杯之量，满杯、dishful 一碟，一碟的量、glassful 一杯的容量。

因此，我们可以去除后面的“ful”后缀，来看前面的单词“REST”。

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

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

Fielding 将他对互联网软件的架构原则，定名为 REST，全称为 Representational State Transfer，翻译成中文则是“表征状态转移”。

如果一个软件的 API 架构符合 REST 原则，我们就称它为 RESTful 架构。

那么，究竟什么是 REST 原则呢？

我相信即使翻译成了中文“表征状态转移”，基本上翻译了等于没翻译。

其实，之所以很难理解，是因为前面的主语被去掉了。REST 的英语全称实际上应该是 Resource Representational State Transfer，对应的中文就是“资源在网络中以某种表现形式进行状态转移”。

感觉好像要稍微好一些了，但是还是模模糊糊的，那么我们就继续拆词。

这里，我们再次将这个翻译进行拆解，可以分为 3 个部分：

Resource：资源，即数据。
Representational State：资源的状态，也就是资源的某种表现形式，比如用 JSON、XML、JPEG 等。
Transfer：（状态）变化。通过 HTTP 动词实现。

下面，我们来针对这 3 个部分依次进行说明。

资源（ Resource ）

所谓“资源”，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。

可以用一个 URL（统一资源定位符）指向它，每种资源对应一个特定的 URL。要获取这个资源，访问它的 URL 即可，而通过前面的学习我们知道，URL 是 URI 的一种具体表现，因此 URI 是每一个资源独一无二的标志符。

所谓“上网”，就是与互联网上一系列“资源”的互动，调用这些资源的 URI。

表现层（ Representation State ）

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

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

图片可以用 JPG 格式表现，也可以用 PNG、GIF 的格式来进行表现。

URI 只代表资源的实体，不代表它的表现形式。

一个资源的具体表现形式，应该在 HTTP 请求的头信息中用 Accept 和 Content-Type 字段来指定，这两个字段才是对资源“表征状态”的描述。

（状态）变化（ Transfer ）

访问一个网站，就代表了客户端和服务器端进行互动的一个过程。在这个过程中，必然会带来资源中数据以及状态的变化。

那么客户端在操作服务器端的某一个资源时，如果告知服务器端该资源的状态变化呢？

这里客户端能用到的手段，就是 HTTP 协议。

还记得前面在介绍 HTTP 请求时，我们有介绍过 HTTP 请求方法支持很多种不同的请求方式么？这其中，有 4 种请求方式分别对应了 4 种基本操作：

GET 用来获取资源
POST 用来新建资源（也可以用于更新资源）
PUT 用来更新资源
DELETE 用来删除资源

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

每一个 URI 代表一种资源。
客户端和服务器之间，传递这种资源的某种表现层。
客户端通过不同的 HTTP 动词，对服务器端资源进行操作，实现"资源表征状态的变化"。

RESTful API 设计示例

好了，关于 RESTful 理论方面的知识我们就介绍这么多，接下来我们来看一点实际的，来看一下使用 RESTful 设计 API 的具体示例。

在 Web 开发早期，后端设计 API 往往会包含对资源进行何种操作的动作信息。

例如：

systemAlias/controller/action

在该 API 中，往往包含了后端使用什么控制器，调用什么方法来对此资源进行操作的信息。

假设要设计一个删除评论的 API，往往设计出来的格式如下：

http://abc.com/?method=comment.del&id=x
http://abc.com/comment/del/id/x

在上面的 API 中，该 URL 已经不仅仅是只包含单纯的资源，还包含了对该资源进行删除操作的“动作”信息在里面，我甚至还能看出后端服务器在处理时，调用的是 comment.del 方法。

接下来我们来对上面的 API 进行修改，改为 RESTful 风格。

因为“资源”仅仅是表示一种实体，所以应该是一个名词，进而 URI 中是不应该有任何动词的。修改出来的 API 如下：

http://abc.com/comments/1

可以看到，这个 API 非常的干净，里面没有任何的动词，仅仅只表示一个资源，一个 id 为 1 的评论资源，除此之外，没有任何其他东西了。

此时，你可能会出现这样的疑问：现在 API 确实是很纯粹了，但是我客户端发一个这样的请求到服务器端，服务器端怎么知道我要对这个资源做什么呢？

很简单，动词的部分虽然从 API 中去除了，但是并不是说没有了，而是将动词应该放在 HTTP 协议中了。由于 HTTP 请求方法支持很多种不同的请求方式，所以要删除一个资源的话，我们可以使用 DELETE 方法。

[DELETE] http://abc.com/comments/1

这也正是 RESTful 风格 API 最大的特点，以 HTTP 协议为强烈依托，之前类似于 http://abc.com/?method=comment.del&id=x 或者 http://abc.com/comment/del/id/x 这种以功能为主导的 URL 风格应该被舍弃，还原 URL 的本质，它的宗旨就是一个 URL 对应的应该是一个实体资源，里面不能包含任何动作。

[POST]     http://abc.com/users   // 新增
[GET]      http://abc.com/users/1 // 查询
[PATCH]    http://abc.com/users/1 // 更新（部分更新）
[PUT]      http://abc.com/users/1 // 更新（全部更新）
[DELETE]   http://abc.com/users/1 // 删除

另外，这里还需要说一下有关 PUT 和 PATCH 两者之间的区别。

PUT 表示更新全部资源，而 PATCH 方法是新引入的，是对 PUT 方法的补充，用来对已知资源进行局部更新。

假设我们有一个 user 对象，里面有 userId、userName、userGender 等 10 个字段。可你的编辑功能因为需求，在某个特别的页面里只能修改 userName，这时候的更新怎么做？

人们通常（为徒省事）把一个包含了修改后 userName 的完整 user 对象传给后端，做完整更新。

但仔细想想，这种做法感觉有点二，而且真心浪费带宽（纯技术上讲，你不关心带宽那是你土豪）。

于是 PATCH 诞生，只传一个 userName 到指定资源去，表示该请求是一个局部更新，后端仅更新接收到的字段。

而 PUT 虽然也是更新资源，但要求前端提供的一定是一个完整的资源对象，理论上来说，如果你用了 PUT，但却没有提供完整的 user 对象，那么缺了的那些字段应该被清空。