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

Question

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

有没有理由为什么HATEOAS客户端应该再次重新发现该资源（和底层表单）而不是使用书签？

那些URL应该保持不变（包括表单语义）吗？重新发现新进化的API（并保证兼容性）比保持旧的API工作更少吗？

Answer 1

在HATEOAS中，URI是可发现的（并且没有记录），因此可以更改它们。也就是说，除非它们是你系统的入口点（Cool URIs，唯一可以被客户硬编码的那些） - 如果你想要能够进化你的其余部分，你不应该有太多这些系统将来的URI结构。这实际上是REST的useful功能之一。

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

Answer 2

HATEOAS不是一个规范，所以应该做什么没有硬性规则。

我认为对于客户来说，最好的做法是只使用书签，只要这些URL所来自的资源是新鲜的。

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

Answer 3

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

后来：

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