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

第 1 部分：什么是 REST 在这一部分中，我们将仔细研究客户端和服务器之间如何进行通信。在此过程中，我们将揭示新术语并对其进行解释。 为了让一切变得清晰，我们将使用一些 RESTful 应用程序的示例来分析客户端-服务器通信。假设我们正在开发一个能够存储有关客户及其订单信息的 Web 应用程序。那些。我们的系统能够操纵一些实体：创建它们、编辑它们、删除它们以及提供有关它们的信息。这些实体将是：

• 客户——客户；
• 订单——客户订单；
• 物品——货物。

在 REST 架构中，客户端向服务器发送请求以获取或修改数据，服务器向客户端发送对其请求的响应。

要求

客户端请求几乎总是通过 HTTP 发出。一般来说，HTTP 请求由以下几个部分组成：

• HTTP 方法；
• 标题;
• 统一资源定位符；
• 请求正文。

下面我们将更详细地了解每个组成部分。

URI 和资源

客户端通过请求获取或修改的数据称为资源。客户端-服务器交互的基础是资源的操作。 REST 中的资源是任何可以命名的东西。从某种意义上说，它们就像 Java 中的类。在 Java 中，我们可以为任何东西创建一个类。在 REST 中也是一样 - 资源可以是任何东西：用户、文档、报告、订单。所有这些可以是某个实体的抽象，也可以是具体的东西，例如文件 - 图片、视频、动画、PDF 文件。对于我们的示例，我们有 3 个资源：

• 客户——客户；
• 订单——客户订单；
• 物品——货物。

客户端将请求发送到所谓的端点或端点。简而言之，端点就像网络上的地址。更深入地说，端点是一个 URI：标识抽象或物理资源的字符序列。Uniform Resource Identifier - 统一资源标识符。有时，端点或 URI 称为路径 - 资源的路径。出于本文的目的，我们将使用术语 URI。每个特定资源必须有一个唯一的 URI。确保每个资源始终具有自己的 URI 的责任落在服务器开发人员的肩上。在我们的示例中，我们是开发人员，因此我们将以我们知道的方式来做。正如在关系数据库中通常习惯将主键设置为某个数字 ID 一样，在 REST 中每个资源都有自己的 ID。通常，REST 中资源的 ID 与存储该资源信息的数据库中的记录 ID 相匹配。REST URI 通常以描述某些资源的名词的复数形式开头。例如，来自“客户”一词。接下来，通过斜线表示 ID——特定客户端的标识符。例子：

• /clients - 所有现有客户端的 URI；
• /clients/23 - 特定客户端的URI，即ID=23的客户端；
• /clients/4 - 特定客户端的URI，即ID=4的客户端。

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

• /clients/4/orders — 4号客户端所有订单的URI；
• /clients/1/orders/12 - 1号客户的12号订单的URI。

如果我们继续这个链条并添加商品，我们会得到：

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

对于嵌套级别，关键是使 URI 直观。

HTTP方式

HTTP Method（英文HTTP Method）是除控件和分隔符之外的任意字符的序列，它指示对资源的主要操作。有几种常见的 HTTP 方法。我们列出了 RESTful 服务中最常用的那些：

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

标题

请求和响应都包含 HTTP 标头。他们发送有关请求（或响应）的附加信息。标头是键值对。您可以在维基百科页面上阅读最常见标题的列表。使用 REST，客户端通常可以在其请求中向服务器发送 Accept 标头。需要让服务器知道客户端期望以什么格式接收其响应。所谓的 MIME 类型列表中提供了各种格式选项。 MIME（多用途互联网邮件扩展）是一种对信息进行编码和格式化消息以便可以通过互联网发送的规范。每个 MIME 类型由两部分组成，用斜杠分隔：类型和子类型。不同类型文件的 MIME 类型示例：

• 文本 - 文本/纯文本、文本/css、文本/html；
• 图像 - 图像/png、图像/jpeg、图像/gif；
• 音频 - 音频/wav、音频/mpeg；
• 视频 - 视频/mp4、视频/ogg；
• 应用程序 - 应用程序/json、应用程序/pdf、应用程序/xml、应用程序/八位字节流。

总的来说，请求可能具有以下标头：

Accept:application/json

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

请求正文

客户端向服务器发送的消息。请求是否有正文取决于 HTTP 请求的类型。例如，GET 和 DELETE 请求通常不包含任何请求正文。但 PUT 和 POST 可以包含：这一切都与请求类型的功能目的有关。毕竟，要通过 id（在 URL 中传输）接收数据并删除它，不需要向服务器发送额外的数据。但要创建新资源（POST 请求），您需要传输此资源。修改现有资源也是如此。在 REST 中，最常使用 XML 或 JSON 格式来传输请求正文。最常见的格式是 JSON。假设我们要向服务器发送请求，并在其中创建一个新资源。如果您还记得，作为示例，我们查看了一个管理客户订单的应用程序。假设我们要创建一个新客户端。在我们的例子中，我们存储有关客户的以下信息： 姓名 电子邮件 电话号码 那么此类请求的正文可能是以下 JSON：

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

将请求放在一起

因此，我们研究了客户端请求可以包含哪些内容。现在让我们给出一些带有描述的查询示例

答案

让我们简单介绍一下服务器的响应。答案通常由以下部分组成：

• 响应代码；
• 标头；
• 响应体。

一般来说，响应标头与请求标头没有太大区别。此外，某些标头同时用于响应和请求。我认为响应正文中的一切也很清楚。正文通常返回客户端请求的信息。对于 GET 请求，可以以相同的 JSON 格式返回信息。但最后一部分更有趣一些。

HTTP 响应代码

让我们仔细看看 HTTP 响应代码。以下是维基百科的引用： HTTP 状态代码是通过 HTTP 协议请求的服务器响应的第一行的一部分。它是一个具有三位小数的整数。第一个数字表示状况的类别。响应代码后面通常是由空格分隔的英文解释性短语，向用户解释此特定响应的原因。例子：

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

客户端从响应代码中了解其请求的结果，并确定下一步要采取的操作。响应代码分为几组：

• 1ХХ - 信息性；
• 2ХХ - 告知成功接受和处理客户请求的案例；
• 3XX——通知客户端为了成功完成操作，需要再次发出请求，通常使用不同的URI；
• 4ХХ - 客户端错误。例如，错误构造的请求或众所周知的 404 Not Found 代码，当客户端请求不存在的资源时可能会发生这种情况；
• 5ХХ - 服务器错误。如果由于服务器故障导致操作失败，则返回给客户端。

您可以在此处阅读有关所有代码的更多信息。 第 1 部分：什么是 REST 第 3 部分：在 Spring Boot 中创建 RESTful 服务