HATEOAS 的良好用例答案

【问题标题】：good use case of HATEOASHATEOAS 的良好用例
【发布时间】：2014-04-29 19:15:43
【问题描述】：

我可以提供一些HATEOAS 的示例/典型用例吗？我同意它可以是一个非常强大的概念，提供了很大的灵活性，但我不确定如何正确地从 HATEOAS 中受益。如果您可以分享您的经验/用例，那就太好了。

【问题讨论】：

【解决方案1】：

来自上述@dreamer 的一个很好的答案，但大多数基于 REST 的服务中不存在 HATEOAS。它是对 REST 架构风格的一种约束，它允许客户端完全通过资源中包含的超媒体与服务进行交互。

如果您查看 Twitter 或 Facebook REST API，您将找不到超媒体。查看 Facebook friendlist 资源。该资源中没有可用于转换资源状态的超文本链接 - 删除、更新等。相反，您需要阅读带外文档以了解删除该资源需要做什么资源。

声称在 API 中使用超媒体的优势之一是您可以管理资源本身的变化。例如，如果 Facebook 想要在好友列表中添加额外的功能怎么办？如果它是在考虑 HATEOAS 的情况下构建的，则将更新资源以添加超链接以提供那些额外的状态转换。

如果这听起来很困难，那你是对的。但是，作为客户端应用程序的开发人员，一旦您了解了超媒体的呈现方式，您就可以构建与 API 本身一起发展的应用程序。

那么如何使用 HATEOAS 构建 API？有很多选择，但我最喜欢Hypertext Application Language (HAL)。

更新：由于您要求提供示例，因此这里有一个使用 HAL 的 demo 的链接。

【讨论】：

没有要删除或更新的链接，部分原因是这些链接不需要存在于 REST 中。这是 RPC 风格的思想。您只需要知道资源本身的 URL，因为已经有内置方法可以 PUT 或 DELETE 资源。
是的，好点。但是如果资源允许其他状态转换呢？这就是超媒体发挥作用的地方。就像允许您下订单的商务应用程序一样？你怎么知道怎么付钱？包含一个支付资源的超链接可以解决这个问题。感谢您的评论。
在订单包含付款信息或已付款的证据之前，您会拒绝接受订单。
是的，这是解决特定问题的一种方法。但有人问了关于 HATEOAS 的问题。如果你采用这种方法，它要求 API 的消费者可以通过使用服务器返回的超媒体来遵循应用程序协议（在这个简单的例子中，订购和支付产品）。
它只要求 API 的使用者不需要事先知道要使用哪些 URL。给定一个入口点，应该可以只使用带内提供的信息进行导航。但前提是导航有意义！例如，朋友列表应该包括每个朋友的 URL。但是结帐过程本质上是有状态的，无论如何这在 REST 中是不受欢迎的。

【解决方案2】：

很难找到好的公共 HATEOAS 用例，因为围绕 REST 存在很多误解，而且 HATEOAS 可能难以实施。你真的需要对它的好处有一个很好的了解，然后你才愿意让自己经历让它工作的麻烦，如果客户没有正确地遵循它，所有的工作都将是徒劳的。

根据我的经验，在公司中实施适当的 REST 是一种文化变革，与转向版本控制系统或敏捷开发一样重要。除非每个人都接受并理解它，否则它带来的麻烦比它解决的要多。

考虑到这一点，我认为最好的例子是 foxycart.com HAL API，在下面的链接中：

【讨论】：

【解决方案3】：

这是一个非常强大的概念，用于RESTful 向客户端展示应用程序。现在有很多项目都在采用这个接口。一个典型的用例是Web Services APIs 使用 RESTful API。一个 RESTful API 通常由以下元素组成：

可以使用上面的HTTP methods 修改应用程序状态，例如，为了获取特定资源，客户端可以使用curl 发出REST query，例如：

curl -X GET --url "http://example.com/resource/" -X "Content-Type:application/json"

您可以通过man pages 了解curl 及其用法。更多关于 RESTful 接口概念可以查看wiki

【讨论】：