是否存在概念验证客户端（即Web应用程序），它代表使用RESTful原则实现并利用RESTful原则的实际应用程序？我所能找到的只是API浏览器，但真实世界应用程序（即社交网络或电子商务网站）的开发却截然不同 .
我已经阅读过Roy的工作和相关论文，但我仍然无法在客户端开发中充分利用Restful . 我总是最终在客户端上存储状态或专门化媒体/类型渲染 . 例如，基于上下文（即在主页上，在产品页面上或在专用的配置文件页面上）不同地呈现相同的资源（即，配置文件资源），从而告别媒体类型 - >按需呈现的代码 .
我真的看不到HATEOAS在具有良好定义/自动生成的IDL（即json超架构）的API上的任何优势（在我的工作方式中） .
我目前的结论是，只有通用客户端（即谷歌）才能从HATEOS而不是真实世界/专业应用程序中受益 . 如果您的API启用了HATEOS而不是IDL，那么专门的客户端开发似乎没有任何好处 .
2 回答
虽然HATEOAS确实为您提供了URI灵活性和人类流动发现，但真正的好处是将其用作资源状态的编码 .
如果您有一个与资源关联的状态机，您将有一些状态允许某些状态转换而不允许其他状态转换 .
通过针对资源URI的操作向REST客户端提供实现可能的状态转换的机会 - 使用HATEAOS超媒体，您可以通过已知的rel链接名称定义转换，然后包含或排除rel链接，具体取决于允许的转换按现状 .
这意味着确定哪些转换有效的逻辑保留在服务器端 - 客户端可以选择隐藏或禁用UI选项，具体取决于是否存在关联的rel链接 .
包括或排除特定rel链接的另一个原因可能与提供给当前用户的访问控制权限有关 . 如果不允许当前用户执行转换，则简单地排除它们 .
如果您没有基于资源状态和/或授权用户的状态动态地包含或排除rel链接，那么您对优点的分析很有意义，因为您没有将它们用于包含它们的真正原因 . 毕竟，REST中的S代表状态！ :)
HATEOS是一种设计理念/风格/风格，这在很大程度上取决于品味或完整代码和手写API之间的权衡 .
HATEOS的关键区别在于将引用构建到API中的其他资源（即通过完整URL） . 如果API响应仅包含ID（而不是资源的完整URL），则会消除您可能遇到的大量文档负担 .
但是，当您使用带有JSON而不是XML的HATEOS时，会丢失一些其他上下文（例如，我应该
PUT或GET或POST到此 endpoints ？）因此，如果要生成一个元数据，则必须使用其他类型的元数据来补充它客户或人类文档 .根据我的经验，与WSDL或IDL相比，HATEOS API更容易使用简单的REST客户端（例如cURL），后者假定客户端使用生成的代码并且永远不会直接触摸API .
Tradeoffs
那么为什么你会选择HATEOS vs WSDL或其他一些生成的选项呢？
API的基本假设（并非总是如此）是它们将具有许多种类的客户端/消费者，可能以不同的语言实现 . 这意味着随着时间的推移，编写和更新客户端比编写服务更有用 .
如果您或您的企业要自己维护API客户端，那么在为所有客户端（WSDL，SWIG等）生成代码或雇用特定于语言的开发人员维护代码之间存在成本权衡 .
机会是生成的API客户端不会遵循任何给定语言的惯用风格，并且代码通常是丑陋的 . 如果这些事情对您很重要，那么您可能需要一个人来编写客户端代码 . 如果您不关心这一点，那么您可以停止阅读有关HATEOS的内容并使用WSDL或类似方法 .
如果您确实希望优化人类使用API，HATEOS之所以成功，是因为它向人类传达了上下文信息，这使得在没有大量API文档的情况下编写客户端变得更加容易 .
Example
有关类似HATEOS的API的示例，请查看GitHub API . 使用REST客户端进行浏览非常容易，一旦了解了如何进行身份验证，就可以通过以下引用的数据URL找到所需的大部分内容 . 您仍然需要参考文档以获取特定的详细信息和高级用例（例如POSTing数据），但是很容易为GitHub编写一个简单的客户端，而无需引入GitHub客户端库或端到端地阅读文档 .