如何在分布式REST服务体系结构中生成HATEOAS链接？ 我是新来休息和做大量的研究现在考虑迁移一个内部的整体服务架构到更瘦和更分散。对于如何在分布式微服务系统中为资源生成HATEOAS链接，我的头脑有点困难。我通常理解为什么不应该将关系本身存储在数据库中，但另一种方法是在代码中生成它们

如果微服务的主要好处之一是允许不同的团队独立工作以改进其服务和API，那么一个团队如何可靠地生成到另一个团队服务资源的链接？这仅仅是关注API中的变更，然后对其进行适当的版本控制，以便其他团队可以随时更新他们的资源链接吗

如果是这样的话，仅仅硬编码链接真的是最好的吗？在我看来，必须有某种最佳实践来实现这一点，我只是对这个场景足够陌生，我一定找不到合适的搜索词

---

谢谢你的帮助

我还没有机会使用HATEOAS实现restapi，但我有时间考虑如何实现它

我想到的最有趣的方法是为restapi实现一种“DNS服务器”，它基本上会构造到系统上可用的不同restapi的url

此“DNS”类型服务将公开以下操作：

GET/api/{resourceTypeIdentifier}/{resourceIdentifier}

这将反过来返回可以使用资源的url

例如：

您的API（比如说提供API）需要返回对其域外资源的引用（比如id为001的客户）。要获取到外部资源的链接，它将调用DNS api，如下所示：

GET/api/offer/001

它将返回一个url，从中有人可以获取关于该资源的其余信息（例如，或）。 只要此DNS的api以通用方式实现，该服务就可以返回所需的复杂url

---

然后，API所有者有责任使用“DNS”API构建URL所需的信息更新“DNS”数据库。这将消除跟踪和更新每个消费者的url的责任，而将其完全放在服务提供商身上。

这是一个有趣的想法，尽管在我看来，你当时真的只是给链接加了个别名，对吗？如果别名应该是静态的，但您的实际关系不是静态的，那么有什么可以阻止您选择快捷方式并直接使用别名作为链接呢？url由以下内容组成：//.//因此您正在对介于“<>”之间的所有内容进行抽象。当然，它们不是经常变化的东西，但如果它碰巧发生了变化，你就不需要在意它。但是一件非常重要的事情是服务的版本控制。您可能总是希望向服务的消费者提供最新版本的api。然后返回到“DNS”类api，以使用最新版本（资源id正确放置在新url上）进行更新，并在响应中返回。@fnmps如果您从未使用过HATEOAS，那么根据Roy Fielding自己的说法，您从未实现过REST api