HATEOAS的灵活性
我正在努力学习如何更好地创建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原理编写逻辑来提出新的请求。
我错了吗 ？
请解释一下这个主要的想法。 我会很感激任何帮助。
谢谢。
我将以相反的顺序回答这些问题，因为我认为（2）的答案将有助于澄清（1）。
是的，大多数客户端应用程序都需要知道如何处理这些可能的资源。 这个想法是让你的客户免于需要知道特定的URI。 如果客户端硬编码或手动跟踪URI，那么服务器无法在不破坏客户端的情况下改变任何路径。 如果客户端跟踪rels，那么API可以灵活地改变其端点的外观。 客户端使用rels不关心URI已经改变。
保持self感觉的原因是为了以后可以使用它。 假设您从其他一些rel获得资源集合。 您可以将它们全部显示在屏幕上。 当用户想要更新其中一种资源时，您如何做到这一点？ 弹出一个包含所有数据的对话框，并在更新并保存后，对self URI执行PUT以更新资源。
另外，有时使用轻量级资源来响应客户端也很方便。 所以说，你要求收集200件东西。 返回200个完整的资源，而不是返回200个完整的资源，它可能有意义返回只有一个name属性和一个self rel的200个对象。 客户端显示200个名称，最终用户选择一个名称，然后客户端在self rel上执行GET操作以下拉该特定资源的所有数据。
HATEOAS允许更改API而无需更改客户端。 它遵循与网站相同的原则。 用户只需要知道主页/域名，并可以通过超链接找出如何从那里导航。
我只会在上述标准有意义的情况下实施真正的RESTful服务。 它会造成很多复杂性。 首先，您必须在服务器上选择适当的内容MIME类型。 有几种不同的建议格式，如HAL或JSON集合，但没有标准。 客户还需要足够聪明才能遵循基于rels的URL。
链接地址: http://www.djcxy.com/p/41023.html下一篇: How useful/important is REST HATEOAS ( maturity level 3)?