HATEOAS 的灵活性

Question

我正在尝试学习如何更好地制作 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，我我对吗？为什么我们需要在链接数组中复制它？
什么是灵活性？在此示例中，有三种（两种没有自我）rel 类型。应用程序如何知道所有这些类型？它们无论如何都应该在代码中硬编码，如果例如引入了新的 rel 类型，我们仍然需要在客户端代码中添加逻辑来处理这种类型的 rel，因此我们需要处理类型rel 或 API 响应不遵循 HATEOAS 原则编写逻辑以发出新请求。

我错了吗？

请说明本文的主要思想。如有任何帮助，我将不胜感激。
谢谢。

Answer 1

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

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

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

此外，有时使用轻量级资源响应客户端也很方便。因此，假设您要收集 200 件物品。与其 returning 200 个成熟的资源，return 200 个只有 name 属性和 self 关系的对象可能更有意义。客户端显示 200 个名称，最终用户选择一个，然后客户端在 self rel 上执行 GET 以提取该特定资源的所有数据。

Answer 2

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

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

HATEOAS 的灵活性

Flexibility of HATEOAS

api

rest

hateoas

restful-url

asp.net-web-api