我是REST新手,现在正在做大量研究,考虑将内部单片服务体系结构迁移到更精简和更分布式的东西。我在思考如何为分布式微服务系统中的资源生成HATEOAS链接时遇到了一些麻烦。我通常理解为什么不应该将关系本身存储在数据库中,但另一种选择是在代码中生成它们。
如果微服务的主要好处之一是允许不同的团队独立工作来改进他们的服务和API,那么一个团队如何可靠地生成到另一个团队的服务资源的链接?这仅仅是关注API中的变化,然后适当地对它们进行版本控制,以便其他团队可以随时更新他们的资源链接吗?
如果是这样,那么硬编码链接真的是最好的吗?在我看来,对于如何做到这一点,一定有某种最佳实践,我只是刚刚接触这一领域,肯定找不到正确的搜索词。
谢谢你的帮助!
发布于 2018-09-27 21:44:57
我还没有机会使用HATEOAS实现REST API,但我有一些时间考虑如何实现它。
我想到的最有趣的方式是为REST实现一种"DNS服务器“,它基本上会构造系统上可用的不同REST的urls。
这个"DNS“类型的服务将公开如下操作:
获取/apis/{resourceTypeIdentifier}/{resourceIdentifier}
该url又将返回可以消耗该资源的url。
示例:
您的API (假设是一个offer API)需要返回对其域外资源的引用(假设是一个id为001的客户)。为了获得外部资源的链接,它将调用DNS api,如下所示:
GET /apis/offer/001
这将返回一个url,人们可以从该url获取关于该资源的其余信息(例如,https://www.example.org/myofferapi/v3/offers/001或https://www.example.org/myofferapi/v3/offers?offerId=001)。只要以通用方式实现该DNS的api,该服务就可以根据需要返回复杂的url。
然后,API所有者将负责使用"DNS“API所需的信息来更新"DNS”数据库,以便构建urls。这将承担跟踪和更新每个消费者上的url的责任,而不是将其单独放在服务提供商身上。
https://stackoverflow.com/questions/52544905
复制