HATEOAS 的灵活性

Posted 2023-03-31

【中文标题】HATEOAS 的灵活性

【英文标题】：Flexibility of HATEOAS

【发布时间】：2016-01-29 12:17:48

【问题描述】：

我正在尝试学习如何更好地制作 REST API，我已经阅读了 HATEOAS，但无法完全理解它的所有灵活性。

有人可以解释为什么它灵活吗？

让我们考虑一下 PayPal HATEOAS API

这里是链接数组的示例

[
  
    "href":"https://api.sandbox.paypal.com/v1/payments/payment/PAY-6RV70583SB702805EKEYSZ6Y",
    "rel":"self",
    "method":"GET"
  ,
  
    "href":"https://www.sandbox.paypal.com/webscr?cmd=_express-checkout&token=EC-60U79048BN7719609",
    "rel":"approval_url",
    "method":"REDIRECT"
  ,
  
    "href":"https://api.sandbox.paypal.com/v1/payments/payment/PAY-6RV70583SB702805EKEYSZ6Y/execute",
    "rel":"execute",
    "method":"POST"
  
]

我了解我们可以提出请求，例如在本例中提供付款信息。

有几个问题

为什么我们需要self 作为rel 的类型，当应用程序发出请求时，它已经知道该资源的完整URL，对吗？为什么我们需要在链接数组中复制它？

灵活性是什么？在这个例子中，有三个（两个没有 self）rel 类型。应用程序如何知道所有这些类型？无论如何，它们都应该在代码中进行硬编码，例如，如果引入了新的rel 类型，我们仍然需要在客户端代码中添加逻辑来处理这种类型的rel，因此我们需要处理rel 的类型或者如果 API 响应不遵循 HATEOAS 原则编写逻辑来发出新请求。

我错了吗？

请解释一下这个的主要思想。如果有任何帮助，我将不胜感激。 谢谢。

【参考方案1】：

我将按相反的顺序回答这些问题，因为我认为 (2) 的答案将有助于理清 (1)。

是的，大多数客户端应用程序都需要知道如何处理可能的 rel 集。这样做的目的是使您的客户无需了解特定的 URI。如果客户端硬编码或手动跟踪 URI，那么服务器永远无法在不破坏客户端的情况下更改任何路径。如果客户端跟踪 rels，则 API 可以灵活地更改其端点的外观。使用 rels 的客户端并不关心 URI 是否已更改。

保留self rel 的原因是为了以后可以使用它。假设您从其他一些 rel 中获取资源集合。您将它们全部显示在屏幕上。当用户想要更新其中一个资源时，你是怎么做的？弹出一个包含所有数据的对话框，在它们更新并点击保存后，您对 self URI 执行 PUT 以更新资源。

此外，有时使用轻量级资源响应客户很方便。所以，假设你要求收集 200 件东西。与其返回 200 个完整资源，不如返回 200 个仅具有 name 属性和 self rel 的对象。客户端显示 200 个名称，最终用户选择一个，然后客户端在 self rel 上执行 GET 以提取该特定资源的所有数据。

【讨论】：

所以无论如何我需要在客户端应用程序中硬编码rel 的类型？不仅类型为文本，而且逻辑如何处理它们？如果我可以根据基本 REST 原则（GET、POST、PUT、DELETE）制作 URL，为什么我需要添加逻辑来处理 rel 的类型？

@CROSP 是的，客户需要知道可能的rels，以便他们可以对它们进行操作。使用rels 允许服务器更改rel 指向的URI。如果服务器决定更改为特定资源提供服务的端点，则使用直接 URI 的客户端将中断。

我想补充一点，rel 并不是通俗意义上的硬编码。可能的 rel 及其含义由客户端支持的 mime-type 定义。客户端明确询问它知道的mime类型，服务器以适当的表示响应。

是的，那个！该死，需要更多角色。

【参考方案2】：

HATEOAS 允许更改 API 而无需更改客户端。它遵循与网站相同的原则。用户只需要知道主页/域，并且可以弄清楚如何使用超链接从那里导航。

我只会在上述标准有意义的情况下实现真正的 RESTful 服务。它会产生很多复杂性。首先，您必须在服务器上选择合适的内容 mime 类型。有几种不同的建议格式，如 HAL 或 JSON 集合，但没有标准。客户端还需要足够聪明才能根据 rels 跟踪 URL。