HATEOAS 以及为什么在 RESTful API 中需要它？

HATEOAS 代表超媒体作为应用程序状态引擎，它是 RESTful API 架构和设计的一个组件。使用 HATEOAS，客户端需要最少的关于如何与服务器交互的知识。这是通过网络应用程序通过使用超媒体动态生成的信息响应客户端的请求而实现的。

当通过浏览器访问网页时，用户可以通过使用按钮、输入、点击链接等方式与网页进行交互。然而，传统的 API 响应没有这样的功能来允许应用程序通过回复。 HATEOAS 是解决这个问题的一种方式。 HATEOAS 请求不仅允许您发送数据，还允许您指定相关操作。

通过 HATEOAS 更改应用程序状态

使用 HATEOAS 架构时，客户端将能够通过简单的静态 RESTful URL 调用访问网络应用程序的 API。现在，客户端可能希望采取的任何进一步操作将由服务器在原始调用中返回的数据启用。这将使客户端能够通过与服务器响应中包含的详细信息交互，从一个应用程序状态移动到下一个应用程序状态。

响应中的“数据”使这种状态改变成为可能，是简单的超媒体链接。这就是 HATEOAS 通过超媒体管理应用程序状态变化的方式。

HATEOAS 使用演示

例如，考虑一个客户端想要与网络应用程序交互以获取组织内员工工资单的详细信息。启用此功能的 RESTful 调用如下所示：

GET /payroll/employee_123 HTTP/1.1

服务器将使用包含所需详细信息的 JSON 进行响应。此外，响应将包含允许客户端采取进一步行动的超媒体链接。例如，考虑服务器的响应如下。

HTTP/1.1 200 OK
Content-Type: application/+json
Content-Length: ...
{
   "payroll": {
       "employee_number": "employee_123",
       "salary" : 1000,
       "links": {
           "increment": "/payroll/employee_123/increment",
           "decrement": "/payroll/employee_123/decrement",
           "close": "/payroll/employee_123/close"
       }
   }
}

我们可以观察到，除了在响应中收到的预期信息之外，在“链接”标题下还以 RESTful 超媒体调用的形式呈现了其他信息。这些链接允许通过增加或减少工资或关闭帐户与服务器进行进一步交互。需要注意的是，这些链接对应于相应的API端点来增加、减少和关闭工资账户。此外，这些链接预先填充了员工标识符。这意味着此类内容是动态生成的。

可以演示如何动态生成这些超媒体链接的另一个示例如下：

假设对于给定的员工，帐户已关闭。因此，递增和递减方法与此类帐户无关。因此，点击此类员工的工资单端点将导致如下响应：

HTTP/1.1 200 OK
Content-Type: application/+json
Content-Length: ...
{
  "payroll": {
      "employee_number": "employee_123"
      "links": {
          "start": "/payroll/employee_123/start"
      }
  }
}

在这种情况下，链接已更改为仅包含与当前状态相关的功能。因此，唯一可用的操作是“启动”此类员工的工资单。

需要 HATEOAS

对于传统的、非基于 HATEOAS 的 API 系统，API 端点需要在客户端应用程序中进行硬编码。对此端点的任何更改都将导致客户端应用程序系统崩溃。因此，需要在每个客户端的应用程序中更新此类更改。因此，该系统是紧密耦合的。

使用 HATEOAS，系统变得松散耦合，因为 URL 不需要硬编码。相反，URL 是在服务器端即时生成并通过 JSON 响应提供给客户端。客户端现在可以使用响应中的这些 URL，并确保这些 URL 是最新版本。