Is there a proof of concept client(i.e. web application) that represents a real-world application implemented using and taking advantage of the RESTful principles? All I could find are API browsers but the development of a real world application(i.e. a social network or ecommerce website) is quite different.
I've read Roy's work and related papers but I still can't gasp how to make the most of Restful in the client development. I always end-up storing state on the client or specialise the media/type rendering. For example the same resource(i.e. profile resource) is rendered differently based on context(i.e. on the homepage, on the product page or on the dedicated profile page) so farewell media-type -> code on demand rendering.
I really can't see any advantage(in the way I work) of HATEOAS over an API with well defined/auto-generated IDL(i.e. json hyper-schema).
My current conclusion is that only generic clients(i.e. google) can benefit from HATEOS not real-world/specialised applications. The specialised client development doesn't seem to take any benefit if your API is HATEOS-enabled instead of being IDL described.
答案 0 :(得分：4)
虽然HATEOAS确实为您提供了URI灵活性和人类流量发现，但真正的好处是将其用作资源 state 的编码。
如果您有一个与资源关联的状态机，您将有一些状态允许某些状态转换，而不允许其他状态。
通过针对资源URI的操作向REST客户端提供实现可能的状态转换的机会 - 使用HATEAOS超媒体，您可以通过已知的rel链接名称定义转换，然后包含或排除rel链接，具体取决于哪个当前状态允许转换。
这意味着确定哪些转换有效的逻辑保留在服务器端 - 客户端可以选择隐藏或禁用UI选项，具体取决于是否存在关联的rel链接。
包含或排除特定rel链接的另一个原因可能与提供给当前用户的访问控制权限有关。如果不允许当前用户进行转换，只需将它们排除在外。
如果您没有动态地包含或排除基于资源状态和/或授权用户状态的rel链接，那么您对优点缺点的分析很有意义，因为您没有使用它们的真正原因包括在内。毕竟，REST中的 S 代表状态！ ：）
答案 1 :(得分：1)
HATEOS是一种设计理念/风格/风格，这在很大程度上取决于成熟代码和手写API之间的品味或权衡。
HATEOS的关键区别之处在于将引用构建到API中的其他资源（即通过完整URL）。如果API响应仅包含ID（而不是资源的完整URL），则会消除您可能遇到的大量文档负担。
但是，当您使用带有JSON而不是XML的HATEOS时，您会失去一些其他上下文（例如，我应该PUT或GET或POST到此端点吗？）所以你如果你想为人类生成客户端或文档，必须用其他类型的元数据补充这一点。
根据我的经验，与WSDL或IDL相比，HATEOS API更容易使用简单的REST客户端（例如cURL），而WSDL或IDL假定客户端使用生成的代码并且永远不会直接触摸API。
<强>权衡
那你为什么要选择HATEOS vs WSDL或其他一些生成的选项？
API的基本假设（并非总是如此）是它们将具有许多种类的客户端/消费者，可能以不同的语言实现。这意味着随着时间的推移，编写和更新客户端比编写服务更有用。
如果您或您的企业要自己维护API客户端，那么在为所有客户端（WSDL，SWIG等）生成代码或雇用特定于语言的开发人员维护一个客户端之间存在成本权衡。< / p>
生成的API客户端很可能不会遵循任何给定语言的惯用风格，而且代码通常很难看。如果这些事情对您很重要，那么您可能需要一个人来编写客户端代码。如果您不关心这一点，那么您可以停止阅读有关HATEOS的内容并使用WSDL或类似方法。
如果您做想要优化人类使用API，HATEOS会成功，因为它会将上下文信息传达给人类，这样可以更轻松在没有大量API文档的情况下编写客户端。
示例
有关类似HATEOS API的示例，请查看GitHub API。使用REST客户端进行浏览非常容易，一旦了解了如何进行身份验证，就可以通过以下引用的数据URL找到所需的大部分内容。您仍然需要参考文档以获取特定的详细信息和高级用例（例如POSTing数据），但是很容易为GitHub编写一个简单的客户端，而无需引入GitHub客户端库或端到端读取文档。