RESTful (HATEOAS) 对专业客户实用吗？

Question

是否有概念验证客户端（即 Web 应用程序）代表使用和利用 RESTful 原则实现的真实应用程序？ 我能找到的只是 API 浏览器，但现实世界应用程序（即社交网络或电子商务网站）的开发却大不相同。

我已经阅读了 Roy 的工作和相关论文，但我仍然不知道如何在客户端开发中充分利用 Restful。我总是最终在客户端上存储状态或专门化媒体/类型渲染。例如，相同的资源（即配置文件资源）根据上下文（即在主页、产品页面或专用配置文件页面上）呈现不同的呈现方式，因此告别媒体类型 -> 按需呈现代码。

我真的看不出 HATEOAS 相对于具有明确定义/自动生成的IDL（即 json 超模式）的 API 有任何优势（在我的工作方式上）。

我目前的结论是，只有通用客户端（即谷歌）可以从 HATEOS 中受益，而不是现实世界/专业应用程序。如果您的 API 支持 HATEOS 而不是 IDL 描述，那么专门的客户端开发似乎没有任何好处。

Answer 1

虽然 HATEOAS 确实为您提供了 URI 灵活性和人工发现流，但真正的好处是将其用作资源状态的编码。

如果您有一个与资源相关联的状态机，您将拥有一些允许某些状态转换的状态，而不是其他状态。

通过对资源 URI 的操作向 REST 客户端提供实现可能状态转换的机会 - 使用 HATEAOS 超媒体，您可以通过已知的 rel 链接名称定义转换，然后根据哪个链接包含或排除 rel 链接当前状态允许转换。

这意味着确定哪些转换有效的逻辑保留在服务器端 - 客户端可以根据关联的 rel 链接是否存在来选择隐藏或禁用 UI 选项。

包含或排除特定 rel 链接的另一个原因可能与提供给当前用户的访问控制权限有关。如果不允许当前用户执行转换，只需将它们排除在外。

如果您没有根据资源状态和/或授权用户的状态动态地包含或排除 rel 链接，那么您对利弊的分析非常准确，因为您没有使用它们的真正原因包括。毕竟，REST 中的 S 代表 state！ :)

Answer 2

HATEOS 是一种设计理念/风格/风格，这在很大程度上是品味问题或成熟代码生成和手写 API 之间的权衡。

HATEOS 的关键区别在于 API 中对其他资源的引用的构造方式（即，通过完整的 URL）。如果 API 响应仅包含 ID（而不是资源的完整 URL），这会消除您可能会遇到的大量文档负担。

但是，当您使用带有 JSON 而不是 XML 的 HATEOS 时，您会丢失一些其他上下文（例如，我应该 PUT 或 GET 或 POST 到此端点吗？）因此您必须用其他一些内容来补充它如果您想为人类生成客户端或文档，则需要一种元数据。

根据我的经验，与假设客户端使用生成的代码并且永远不会直接接触 API 的 WSDL 或 IDL 相比，人类使用简单的 REST 客户端（例如 cURL）更容易使用 HATEOS API。

权衡

那么您为什么要选择 HATEOS 与 WSDL 或其他生成的选项？

API 的基本假设（并非总是如此）是它们将有多种客户端/消费者，可能以不同的语言实现。这意味着随着时间的推移，编写和更新客户端比编写服务更多的工作。

如果您或您的企业要自己维护 API 客户端，那么在为所有客户端（WSDL、SWIG 等）生成代码或聘请特定语言的开发人员来维护代码之间需要权衡取舍。

很可能生成的 API 客户端不会遵循任何给定语言的惯用风格，而且代码通常很难看。如果这些事情对您来说很重要，那么您可能需要一个人来编写客户端代码。如果您不关心这一点，那么您可以停止阅读有关 HATEOS 的内容并改用 WSDL 或类似方法。

如果您确实想要针对人类使用 API 进行优化，HATEOS 会成功，因为它将上下文信息传达给人类，这使得它更容易在没有大量 API 文档的情况下编写客户端。

示例

有关 HATEOS 类 API 的示例，请查看 GitHub API。使用 REST 客户端进行浏览非常容易，一旦您了解了如何进行身份验证，您就可以通过遵循引用的数据 URL 找到大部分您想要的东西。您仍然需要参考文档以获取特定细节和高级用例（例如发布数据），但是为 GitHub 编写一个简单的客户端非常容易，而无需拉入 GitHub 客户端库或端到端阅读文档。