REST 概述。第 2 部分：客户端和服务器之间的通信

REST 概述。第 1 部分：什么是 REST？ 在这一部分中，我们将深入探讨客户端和服务器之间如何进行通信。在此过程中，我们将发现新术语并对其进行解释。 为了确保一切都清楚，我们将使用 RESTful 应用程序作为示例来分析客户端-服务器通信。假设我们正在开发一个 Web 应用程序来存储有关客户及其订单的信息。换句话说，我们的系统能够对某些实体执行操作：创建、编辑和删除它们，并显示有关它们的信息。这些实体将是：

• 客户（客户）
• 订单（客户订单）
• 项目（产品）

在 RESTful 架构中，客户端向服务器发送请求以检索或修改数据，然后服务器向客户端发送对其请求的响应。

要求

客户端请求几乎总是使用 HTTP 协议进行的。通常，HTTP 请求由几个部分组成：

• HTTP方法
• 标头
• 网址
• 请求正文

下面我们将更详细地考虑每个组件。

URI 和资源

客户端通过请求接收或修改的数据称为资源。客户端-服务器通信都是关于操纵资源的。在 REST 中，资源是您可以为其命名的任何东西。从某种意义上说，它们就像 Java 中的类。在 Java 中，我们可以为任何东西创建一个类。所以在 REST 中，资源可以是任何东西：用户、文档、报告、订单。它可以是某个实体的抽象，也可以是特定的东西，例如图像、视频、动画或 PDF 文件。在我们的示例中，我们有 3 个资源：

• 客户（客户）
• 订单（客户订单）
• 项目（产品）

客户端将请求发送到称为端点的资源位置。简而言之，端点就像网络上的地址。深入研究，我们可以说端点是一个URI，即标识抽象或物理资源的字符序列。统一资源标识符 (URI) 有时端点或 URI 称为路径，表示资源的路径。出于本文的目的，我们将使用术语 URI。每个特定资源都必须具有唯一的 URI。服务器开发人员负责确保每个资源始终具有自己的 URI。在我们的示例中，我们是开发人员，因此我们将按照我们知道的方式进行。正如通常习惯将数字标识符分配为关系数据库中的主键一样，每个资源在 REST 中也有自己的 ID。REST 中的资源 ID 通常与存储资源信息的数据库中记录的 ID 相匹配。REST URI 通常以描述某些资源的名词的复数形式开头。例如， ”

• /customers — 所有可用客户的 URI
• /customers/23 — 特定客户的 URI，即 ID=23 的客户
• /customers/4 — 特定客户的 URI，即 ID=4 的客户。

但这还不是全部。我们可以通过添加命令来扩展 URI：

• /customers/4/orders — 第 4 位客户下的所有订单的 URI
• /customers/1/orders/12 — 1 号客户制作的 12 号订单的 URI。

如果我们通过添加更多产品来继续扩展，我们会得到：

• /customers/1/orders/12/items — 1 号客户制作的 12 号订单中所有产品列表的 URI。

当我们添加嵌套级别时，重要的是使 URI 直观。

HTTP方法

HTTP 方法是任意字符（控制字符和定界符除外）的序列，表示对资源执行的主要操作。有几种常见的 HTTP 方法。我们将列出 RESTful 服务中最常用的那些：

• GET — 获取有关特定资源（通过其 ID）或资源集合的信息
• POST——创建一个新资源
• PUT — 更改资源（通过其 ID）
• DELETE — 删除资源（通过其 ID）

标头

请求和响应都包含 HTTP 标头。它们传达有关请求（或响应）的附加信息。标头是键值对。您可以在维基百科上查看最常见的标题列表。对于 REST，客户端通常会在请求中向服务器发送一个“Accept”标头。需要此标头来告诉服务器客户端希望以何种格式接收响应。MIME 类型列表中给出了各种格式。 MIME（多用途 Internet 邮件扩展）是一种编码信息和格式化消息的规范，因此它们可以通过 Internet 发送。每个 MIME 类型都由斜线分隔的两部分组成 — 类型和子类型。不同类型文件的 MIME 类型示例：

• text — text/plain, text/css, text/html
• 图像 — 图像/png、图像/jpeg、图像/gif
• 音频 — 音频/wav，音频/mpeg
• 视频 — 视频/mp4，视频/ogg
• application — application/json, application/pdf, application/xml, application/octet-stream

例如，一个请求可以有一个像这样的标题：

Accept:application/json

此标头告诉服务器客户端希望收到 JSON 格式的响应。

请求正文

这是客户端发送给服务器的消息。请求是否有主体取决于 HTTP 请求的类型。例如，GET 和 DELETE 请求一般不包含任何请求体。但是 PUT 和 POST 请求可以——这只取决于请求的目的。毕竟，要使用 ID（在 URL 中传递）接收和/或删除数据，您不需要向服务器发送额外的数据。但是为了创建新资源（通过 POST 请求），您需要发送资源。修改现有资源也是如此。在 REST 中，请求主体通常以 XML 或 JSON 格式发送。JSON 格式是最常见的。假设我们要向服务器发送请求以创建新资源。如果你还没有忘记，我们考虑了管理客户订单的应用程序示例。假设我们要创建一个新客户。在我们的案例中，我们存储以下客户信息：姓名、电子邮件、电话号码。然后请求的主体可以是以下 JSON：

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

将请求放在一起

因此，我们已经检查了客户请求中可能包含的内容。我们现在将给出一些请求示例以及描述

回应

让我们谈谈服务器响应。响应通常由以下部分组成：

• 响应代码
• 标题
• 响应体

通常，响应标头与请求标头没有太大区别。此外，一些标头用于响应和请求。我认为关于请求正文的一切也都很清楚。主体通常会返回客户端请求的信息。响应 GET 请求返回的信息也可能是 JSON 格式。但最后一部分更有趣。

HTTP 响应代码

让我们更详细地考虑 HTTP 响应代码。HTTP状态代码是服务器响应通过 HTTP 协议发出的请求的第一行的一部分。它是由三位十进制数字组成的整数。第一位表示响应状态代码的类别。响应代码通常后跟英文解释性短语，以空格分隔。该短语是响应的人类可读原因。例子：

• 201 创建
• 401未经授权
• 507 存储空间不足

响应代码告诉客户端请求的结果，并允许它确定下一步要采取的操作。响应代码分为几类或几组：

• 1XX — 信息性
• 2XX — 这些代码表示已成功接收并处理了客户端的请求
• 3XX — 这些代码通知客户端必须发出额外的请求，通常是针对不同的 URI，才能成功完成操作
• 4XX — 客户端错误。此类代码可能来自错误组合的请求。另一个例子是众所周知的“404 Not Found”代码，当客户端请求不存在的资源时会发生这种情况
• 5XX — 服务器错误。如果服务器对操作失败负责，这些代码将返回给客户端

REST 概述。第 3 部分：在 Spring Boot 上构建 RESTful 服务