是否有可能在微服务世界中进行超媒体驱动的RESTFul服务?

时间:2016-12-15 23:26:26

标签: microservices restful-architecture hypermedia

让我们说我们正在创建一个票务处理系统。假设此域中有两个不同的有界上下文。 取消机票 更改故障单

据我所知,这两个可以是两个不同的微服务,而不必彼此了解。取消服务的票证可能与票证与更改服务的票据完全不同。

从REST API设计的角度来看,我已经阅读了很多关于使用超媒体和让客户通过将相关操作作为REST响应中的链接(Stefan Tilkov's Talk)来发现资源的内容。如果这是真的,当我的变更服务返回响应时,包含取消服务的链接是有意义的,客户端可以使用该链接来执行取消。当取消和更改是两个不同的微服务时,我怎样才能实现这一点?或者我的有限背景是错的?

在使用微服务时,我们是否会失去这些超媒体链接功能(或者变得更难)?

由于 凯

1 个答案:

答案 0 :(得分:0)

在HATEOAS中,URI是可发现的(并且没有记录),因此可以更改它们。也就是说,除非它们是您系统的入口点(Cool URIs,唯一可以由客户进行硬编码的入口点) - 如果您想要这种能力,那么您不应该拥有太多的入口点在将来改进系统的其他URI结构。这实际上是REST的useful最多功能之一。

对于剩余的非酷URI,它们可以随着时间的推移而改变,并且您的API文档应该说明应该在运行时通过超媒体遍历发现它们。

话虽如此,在你的场景中,链接将是一个酷URI,而不是相对于当前的API(因为它可能驻留在不同的机器/域等)。除非您使用某些discovery tool,否则您将不得不对该链接进行硬编码,从而失去可发现性的好处。