REST 架构-架构快速进阶教程
1. 简介
REST 是一种软件架构风格,它依赖于描述如何定义和访问资源的规则。很难想象没有RESTful API的现代互联网。在本文中,我们将深入探讨 REST 和相关 HTTP 概念。
2. REST 架构
正如我们提到的,REST是一种软件架构风格。另一方面,它不是标准化的(如SOAP)。它在实施方面提供了很大的弹性。例如,没有单一且适当的方法来实现分页。因此,REST 定义了在开发 RESTful API 时要遵循的一组主要的、一般的约束。让我们定义它们。
2.1. 约束
- 统一的界面。应在请求中确定具体资源。通常,它们由统一资源标识符 (URI) 描述。此外,内部实现与资源表示是分开的。此外,表示应提供修改或删除资源或获取附加数据的所有信息。
- 客户端-服务器体系结构。客户端使用 URI 获取资源。它不涉及服务器如何处理请求。另一方面,服务器处理并返回资源。它不会以任何方式影响用户界面。客户端和服务器都不需要了解其他职责。因此,它们可以独立进化。它允许在许多不同的客户端中使用单个API,例如Web浏览器,移动应用程序。
- 无国籍。RESTful API 应该是无状态的。简而言之,这意味着它不存储有关用户会话的任何信息。因此,每个请求都应提供完整的数据来处理它。因此,它导致 API 的可用性更高。
- 可缓存性。服务器的响应应提供有关是否应缓存以及缓存时间的信息。缓存更新的数据很少能提高性能并消除冗余的客户端-服务器交互。
- 分层系统。REST API 可以由多个层组成,例如业务逻辑、表示、数据访问。此外,图层不应直接影响其他图层。此外,客户端不应知道它是否直接连接到终端服务器或中介。因此,我们可以轻松扩展系统或提供其他层,例如网关、代理、负载均衡器。
- 按需编码。这是一个可选约束。服务器可以返回代码本身的一部分,而不是 JSON 格式的数据。关键是对客户端可以直接使用的数据提供特定操作。虽然,这不是一种常见的做法。
3. HTTP协议
考虑到REST,我们通常会想到基于HTTP的应用程序。虽然,可以将 REST 用于不同的协议,但这种情况很少发生。因此,在本节中,我们将重点介绍 HTTP 协议及其在 REST 中的用法。
首先,HTTP协议是万维网的协议。它定义了客户端和服务器之间的通信规则。HTTP 是无状态的,它以请求-响应方式工作。
客户端发送与某些资源相关的请求。它可以是HTML网站,文件或javascript代码。HTTP 没有定义资源应该是什么。每个资源都有自己的标识符调用 URI。URI 的一般结构如下所示:
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
为了澄清,让我们看一个真实世界的例子:
URI 只是 HTTP 请求的一部分。该请求包括:
- 包含路径、协议版本和 HTTP 方法的请求行
- 零个或多个标头
- 指示标头结尾的空行
- 可选主体
3.1. 方法
我们已经知道,HTTP 请求由请求行和 HTTP 方法组成。HTTP 方法描述客户端要对资源执行的操作。有四种最常用的基本方法:获取、发布、放置和删除。让我们定义它们。
第一个,GET用于读取资源。服务器返回给定 URI 的资源。GET 方法不包含正文。它只获取资源,不会以任何方式修改它。
第二个,POST用于将数据传输到服务器。因此,它通常与创建资源相关联。数据在正文中发送。创建资源后,服务器应使用其 URI 进行响应。
下一个,PUT类似于POST。虽然,它有很大的不同。它用于更新现有资源。它用传输的数据覆盖整个资源。PUT与POST不同的主要属性是PUT是一个幂等操作。这意味着多次使用相同的数据调用 PUT 将始终给出相同的结果。它没有任何副作用。此外,PUT 指向现有资源。而 POST 会创建一个新的。
最后的基本方法是删除。顾名思义,它用于删除现有资源。
还有其他方法,有时可以使用:补丁,头,选项,连接和跟踪。虽然,很少使用,我们不会在本文中介绍它们。
3.2. 代码
HTTP 响应附带响应代码。它通知操作的结果。它对 UI 开发人员特别有用,因为他们可以根据代码执行适当的操作。有以下一组 HTTP 响应代码:
- 1xx – 信息性 – 表示已收到请求并继续该过程。示例包括:100 – 继续,101 – 交换协议
- 2xx – 成功 – 收到、理解并成功处理请求时。众所周知的例子是 200 – OK 和 201 – 创建
- 3xx – 重定向 – 客户端需要采取其他操作来满足请求,例如,300 – 多项选择或 301 – 永久移动
- 4xx – 客户端错误 – 表示客户端存在错误,例如 400 – 错误请求或 401 – 未授权
- 5xx- 服务器错误 – 通知服务器端发生错误,例如,500 – 内部服务器错误,501 – 未实现
4. 理查森成熟度模型
简而言之,Richardson 成熟度模型估计了对 RESTful API 要求的遵守程度。该模型定义了四个级别。如果 API 满足所有这些要求,则意味着它完全实现了模型。因此,它表明考虑到 REST 约束,API 的质量很好。
0级被称为痘沼泽。在这个层面上,API并没有使用HTTP协议的全部潜力,通常,它只使用POST和GET方法。因此,HTTP 协议仅用作传输层。此外,大多数返回响应代码 200。此外,实现不依赖于明确定义的 URI。级别 0 API 的示例终结点可能如下所示:
POST /api/createUser
POST /api/updateUser
GET /api/findUser
级别 1 API 定义资源及其 URI。虽然,仍然没有使用其他HTTP方法和响应代码。级别 1 API 的示例 URI 包括:
POST /api/users/create
GET /api/users/{id}/find
POST /api/users/{id}/update
在第 2 级,API 使用除 GET 和 POST 之外的其他 HTTP 方法,例如 PUT、PATCH 或 DELETE。因此,可以更好地定义 URI。此外,API 使用更有意义的 HTTP 响应代码。下面,我们可以看到一个示例级别 2 API 端点:
POST /api/users
PUT /api/users/{id}
GET /api/users/{id}
最后,第 3 级,示例是一个自我导航的 API。它增加了一些复杂性,因此不经常使用。简而言之,我们添加与所需资源相关的其他资源的 URI。为了澄清,让我们看下面的例子。在用户响应中,我们嵌入了一个地址 URI,通过使用它,客户端可以获取地址详细信息。
{
"id":12345,
"firstname":"some-firstname",
"lastname":"some-lastname",
"age":39,
"links":{
"address":"users/12345/address"
}
}