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

Question

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

HATEOAS客户端是否应该再次重新发现该资源（和底层表单）而不是使用书签？

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

Answer 1

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

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

Answer 2

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

我认为客户的最佳做法是只在这些网址来自新资源的情况下使用书签。

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

Answer 3

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

稍后：

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