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

我错了吗？

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

Answer 1

我将以相反的顺序回答这些问题，因为我认为（2）的答案将有助于澄清（1）。

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

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

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

Answer 2

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

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

HATEOAS

2 个答案: