Rest API Hateoas：API响应中的标识符应为硬编码还是占位符？

Question

Link to the HATEOAS这是Hateoas文章的链接（下面的快照），其中资源的标识符是URL的一部分，即12345。此处，API响应具有最终的API相对URL，即/ accounts / 12345 / deposit和客户只需要点击它即可。

Link to the Github Users API这是到Github API的链接（下面的快照），其中有很多标识符的占位符。客户将如何修改这些URLS并在这些占位符中添加值？例如，{/ gist_id}，{/ other_user}。

不是通过ID值代替占位符传递URL更好吗？为什么以及何时依靠不同的客户在这些占位符中添加值？

Answer 1

超文本作为应用程序状态（HATEOAS）的引擎，不仅仅是链接的使用。从本质上讲，它成功实施了二十年来在Web上使用的交互模型。在网络上，服务器通常会通过link relations来“教”客户端（浏览器）以实现某些目标，这些目标可用于自动下载相关资源或提示参考资源，而Web forms则定义了各个支持的（输入）元素（即，文本字段，用于选择一个或多个选项的选项元素，下拉菜单甚至是滑块小部件）中每个元素的语法和语义。根据每个元素的affordance，客户端知道，即，想要单击或按下按钮，而文本字段需要一些用户输入和填充，则可以自动下载带有prefetch链接关系名称的链接当前页完成加载后，客户端可能会接着调用它，或者preload链接关系可能会指示用户代理在当前页加载过程中尽早加载引用的资源。

Answer 2

对于您的最佳示例（银行），您绝对应该包括带有帐号（ID）的完整URL，以便客户无需翻译/替换任何内容。这是HATEOAS最常见的情况。但是，GitHub确实为那些可能包含多个值的端点提供了“占位符”。您不能在响应中为每个用户都包含“ following_url”，这是不切实际的。因此，您必须用另一种方法确定“ other_user”值并进行替换。就个人而言，我的所有应用程序都没有这个用例，而且我的所有HATEOAS URL都与您的第一个示例相似（尽管我更喜欢完整URL，而不是相对URL）。除非您有类似GitHub的特殊情况，否则没有必要使用任何这些占位符。甚至GitHub也只在可能是多个值的地方使用它。对于固定值URL，它们在URL（“ octocat”）中具有用户名（如您的帐号）。

Answer 3

据我说，我们不应在正文中提供直接网址我们应该始终将api参数化，并在那里获取详细信息。在简单的情况下，如果数据ID发生变化，则每次需要更新详细URL的数据。否则，如果它是动态的，您将永远不会遇到这个问题。这也是最佳做法。