我是REST的新手,现在正在做大量研究,以考虑将内部整体式服务体系结构迁移到更精简,更分布式的系统中。我在解决如何为分布式微服务系统中的资源生成HATEOAS链接时遇到麻烦。我通常理解为什么您不应该将关系本身存储在数据库中,但是替代方法是在代码中生成它们。
如果微服务的主要好处之一是它们允许不同的团队独立工作以改善其服务和API,那么一个团队如何可靠地生成与另一团队的服务资源的链接?
如果是这样,仅对链接进行硬编码真的最好吗?在我看来,如何做到这一点必须有某种最佳实践,我对这个场景还很陌生,因此我不能找到正确的搜索词。
感谢您的帮助!
答案 0 :(得分:0)
我没有机会使用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的责任,而将其仅放在服务提供商上。