问题描述
我正在了解 HATEOAS。我正在使用的后端服务器将使用使用 HATEOAS 的第三方 REST API。该 API 有一个端点，用于返回每个资源的 url，并通过常规请求返回相关资源链接。
但我想知道在服务器上管理这些链接以避免对它们进行硬编码的好方法是什么。例如，如果第三方更改了资源的 url，服务器将如何检测到该更改？是否有管理 HATEOAS 资源链接的标准做法？
我能想到的可能方法
但这两种方式听起来都不像是稳健的方式。
解决方法
虽然发现通常是一件好事，并且应该允许 HATEOAS 系统以“硬编码 url”不会的方式引入更改，但如果 url 开始任意破坏，我仍然会认为这是一个主要问题。
您应该能够将网址/链接存储在您身边，并希望它们继续工作。
虽然有一些机制可以处理变化：
- 如果资源移动，服务器应返回
301/308重定向。如果是这种情况，您还应该更新您的参考资料。 - 服务器可以发出
Sunset或Deprecated标头。请参阅：https://tools.ietf.org/html/rfc8594
这些是更一般的答案，但最终最佳实践的存在并不意味着供应商会遵守它们。考虑到这一点，我认为最好的办法是尝试找出供应商的弃用政策，然后看看他们推荐什么。
,- 如果缓存资源有效，则使用缓存资源，当您没有本地有效副本时请求刷新。
RFC 7234 定义了 HTTP 的缓存语义。
理想情况下，您不自己实现缓存规则，而是使用通用缓存。
在理想形式中，您的定制实现是与无头浏览器对话，而无头浏览器会为您担心缓存规则。
,理论上，您需要初始 URL 来启动进程，其他一切都来自于此。
您从服务器获取的每个资源都应包含指向该资源服务图中其他边的链接。
因此，一旦您获得初始资源，其余所有资源都会自动出现。
也就是说，拥有“众所周知的”入口点，理想情况下是不变的 URL，这并没有什么不妥。但归根结底，那些只是“书签”，不一定保证终点。
考虑一个购物网站，例如亚马逊。在 amazon.com 之外，您不知道他们的任何 URL。它们都在各种形式和页面上提供，人们只需浏览网站。这些 URL 可能一直在变化，没有人会知道。使用 HATEOAS，由机器来跟踪链接，而不是人类。但是导航的过程是一样的。
正如其他人所提到的，缓存根资源的想法是有价值的。然后您依靠缓存标头来指导您刷新链接的频率。
但这就是说，在操作上，遵循普通链接和遵循缓存链接之间没有区别。在下面，缓存资源加载速度更快，但您仍然需要“跟随链接”。因为这是缓存行为开始的地方。这与假设链接良好、假设您知道资源查找的结果不同。您的应用程序遵循链接。总是。底层基础架构负责使其高效。
所以，你的代码不应该，比如说，加载一个根资源，然后填充一个充满链接的地图，然后假设它们是好的。相反，代码应该请求根资源，也许作为链接映射（win 的数据类型），并让下一层处理细节。因为这完全取决于所涉及的缓存类型。有些有编码的持续时间，不需要跟进。其他人，您无论如何都会发出请求，服务器层会回复“没有任何变化”，因此您可以使用本地副本，但您仍然需要首先询问。
那些是 SERVER 要求的实现细节（不是客户端）。这是一个服务器合同。如果他们希望你每次都 ping 他们，就这样吧。这是他们向您提供的合同，如果您想成为一名好公民，那么您应该尊重这种联系。
理想情况下，服务器会出于效率考虑对此类问题做出正确的决定，但最终还是由他们自己决定。
客户必须跟着。 HATEOAS 系统中的客户端向服务器转让了很多东西。它们根本不是由客户做出的决定。