rest - 如何在分布式 REST 服务架构中生成 HATEOAS 链接？

Question

我是 REST 的新手，现在正在做大量研究以考虑将内部单体服务架构迁移到更精简和更分布式的架构。我在思考如何为分布式微服务系统中的资源生成 HATEOAS 链接时遇到了一些麻烦。我大致理解为什么您不应该将关系本身存储在数据库中，但替代方法是在代码中生成它们。

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

如果是这样，是否真的最好只对链接进行硬编码？在我看来，必须有某种最佳实践来执行此操作，我对这个场景还很陌生，所以我一定找不到正确的搜索词。

感谢您的帮助!

Answer 1

我还没有机会使用 HATEOAS 实现 REST API，但我有一些时间思考如何实现它。

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

这种“DNS”类型的服务会公开如下操作:

GET/apis/{resourceTypeIdentifier}/{resourceIdentifier}

这将依次返回可以使用资源的 url。

例子:

您的 API(假设是优惠 API)需要返回对其域外资源的引用(假设是 ID 为 001 的客户)。要获取外部资源的链接，它将像这样调用 DNS api:

获取/apis/offer/001

这将返回一个 url，从那里有人可以获取有关该资源的其余信息(例如，https://www.example.org/myofferapi/v3/offers/001 或 https://www.example.org/myofferapi/v3/offers?offerId=001)。只要此 DNS 的 api 以通用方式实现，该服务就可以返回所需的复杂 url。

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