HATEOAS API 客户端不应该使用书签 URL 吗？ [关闭]答案

【问题标题】：Should HATEOAS API client not use bookmarked URLs? [closed]HATEOAS API 客户端不应该使用书签 URL 吗？ [关闭]
【发布时间】：2016-07-24 10:30:56
【问题描述】：

假设我想编写一个显示产品价格的应用程序。我发现了一个使用超媒体的链接，这是一种将产品名称作为输入的 HTML 表单。我将其添加为书签并继续将该链接嵌入到客户端中。

HATEOAS 客户端是否有理由再次重新发现该资源（和基础表单）而不是使用书签？

难道这些 URL 不应该保持完整（包括表单语义）吗？重新发现新演进的 API（并保证兼容性）是否比保持旧 API 工作更轻松？

【问题讨论】：

投票决定重新打开它，因为这是一个非常现实的问题，有人潜入 HATEAOS 可能会遇到。这可能没有一个明确的二元答案，但绝对可以客观地讨论解决方案的优缺点。
@Evert 我同意你的看法。由于 REST 几乎是 Web 上使用的概念的概括，“HATEOAS API”只不过是一个 HTTP 端点，它生成一个包含客户端可以使用的一些链接的答案。由于 HTTP 客户端（浏览器）可以为页面添加书签，因此在 REST 中也应该是可行的。这不是意见，而是纯粹的事实。 Some questions 在没有正确思考或对手头的事情有错误理解的情况下关闭（非“专家”）

标签： rest restful-url bookmarks hateoas discoverability

【解决方案1】：

在 HATEOAS 中，URI 是可发现的（并且没有记录），因此可以更改它们。也就是说，除非它们是您系统的切入点（Cool URIs，唯一可以由客户端硬编码的切入点） - 如果您想要进化其余部分的能力，您不应该拥有太多的切入点未来系统的 URI 结构。这实际上是 REST 最useful 的特性之一。

对于剩余的非酷 URI，它们可以随着时间的推移而更改，并且您的 API 文档应该说明它们应该在运行时通过超媒体遍历发现的事实。

【讨论】：

【解决方案2】：

HATEOAS 不是规范，因此没有硬性规定应该做什么。

我认为客户的最佳做法是，只要这些 URL 的来源是新鲜的，就使用书签。

对于服务器而言，最佳做法是保持旧 URL 方案正常工作，并在必要时将旧 URL 重定向到新 URL。

【讨论】：

【解决方案3】：

将书签视为缓存 URI。您不能确定您的缓存是否包含实际的 URI。您不能将该 URI 保留太久，或者您需要检查它是否不是 404。在后一种情况下，您可以尝试重新发现它。我不认为重新发现总是可能的或值得付出努力。例如。如果您通过分页找到 URI 并且它位于第 1000 页，那么除非您保存页码，否则重新发现它的成本很高，这可能会改变...我认为您需要某种书签服务来应对这些情况。例如。您可以提供传递给 URI 模板的参数和资源类型，或者您可以将旧 URI 提供给该服务，它应该返回新的 URI。我不知道什么是理想的解决方案。

稍后：

与此同时，我与 REST 专家讨论了这个问题，但我们无法就正确的解决方案达成一致。他们提出了日落标头或弃用标头，但都告诉客户端该资源将被删除。我认为这里不是这种情况，因为我们保留了资源并且只有 URI 发生了变化，所以在我们的例子中资源将被移动。我们有一个 301 移动的标题，我们可以使用重定向。我想一段时间后我们可以将其更改为 404 并添加一条错误消息，说明 URI 已更改。后面我们可以去掉路径，不用解释就返回404。

【讨论】：