我很难看到HATEOAS和微服务如何共存。
我们举一个例子：
假设我们有购物车资源。 我们需要将产品的快照放入其中，例如产品编号，产品价格;项目添加到购物车时的当前价格快照，以及可能的其他一些值。 实际的用例并不重要，只是为了对手头的问题有所了解。
当我之前做过HATEOAS时，我会在购物车资源中放置链接到产品的链接或链接到特定产品的模板网址。
这样，客户端仍然可以不知道资源URL。
但在微服务领域，服务应该不了解其他服务。 AFAIK。
那么他们怎么能一起工作呢？
我对微服务的解释是，他们永远不能链接到除他们自己以外的任何东西，这几乎就是Self链接。
我在其他地方发现了同样的问题，例如： https://groups.google.com/forum/#!topic/api-craft/YRkLFVY_zFc
使用像所有这些编织在一起的“宏服务”之类的解决方案。 这似乎不是一种解决问题的简洁方法。
[编辑]
我在这个主题上找到了一些更好的信息： https://github.com/Netflix/eureka https://github.com/RestExpress/HyperExpress
这似乎很好，有一些工具用链接来扩充资源，但这让我想到，决定资源应该属于什么链接的逻辑在哪里？ 在公开资源的服务中？ 在中央服务注册中心？
答案 0 :(得分：7)
但在微服务领域，服务应该不了解 其他服务。 AFAIK。
我认为这是你困惑的根源。我的理解是，为了软件开发，服务不应该依赖带外信息与其他服务进行通信。这意味着服务不应该对其同行的内部知之甚少，但是说它不应该知道其他服务也没有任何意义。这与HATEOAS没有冲突，事实上，它们相互补充。
链接到其他服务没有问题。你怎么会从微服务建立一个宏服务？依靠带外信息存在问题。
答案 1 :(得分：1)
服务的调解，编排和编排不受限制 SOA，但同样适用于微服务架构。
意思是微服务可以与其他微服务通信以传递或获取一些信息。 例如，微服务也需要依赖于容器堆栈中的有状态数据存储。所以它需要知道（RESTFull）数据库的API /接口..
HATEOAS主要提供接口和通信设计 模式，所以你可以免于说固定的接口定义语言 像WSDL或Swagger。
尽管REST（HTTP）已经成为最有名的，但它有时被视为微服务将作为REST API使用，但事实并非如此。
微服务的美妙之处在于它们不会将您限制在一个或多个 两种沟通模式，其独立性。没有标准。
例如，反应式微服务强调使用消息驱动的通信模式并且变得彼此透明。但这并不意味着不知道动词和动词。其他微服务的有效载荷传递或检索。
同样，我们可以在微服务架构中内置基于HATEOAS的通信模式，以便完全灵活地适应不断变化/升级的微服务接口。但总的来说，您需要知道要与之通信的微服务的位置。 因此，服务发现和服务注册模式存在于微服务中;它们同样适用于HATEOAS架构。 我们的微服务容器可以根据负载生存和死亡（向外扩展和向下扩展）;我们的客户经常需要知道要消费的微服务的活动位置。