HATEOAS and Microservices

Question

I'm having some serious trouble seeing how HATEOAS and Microservices can co-exist.

Let's take an example:

Let's say we have a shopping cart resource. And we need to put snapshots of products into it, e.g. product Id, product price; snapshot of current price when item was added to cart, and possibly some other values. The actual use-case is not relevant, but just to get some idea on the problem at hand.

When I have been doing HATEOAS earlier, I would have put a link in the shopping cart resource that links to products or a template url that links to a specific product.

This way, the client can still be ignorant of resource URL's.

But in the microservice world, a service should have no knowledge of other services. AFAIK.

So how could they both work together?

My interpretation of microservices is that they can never link to anything else than themselves, which would pretty much be a Self link.

I've found the same question asked on ther places, e.g. https://groups.google.com/forum/#!topic/api-craft/YRkLFVY_zFc

Where solutions like "macro services" that weave all this together is used. Which doesn't seem like a clean way to solve things.

[Edit]

I've found some more nice info on the topic: https://github.com/Netflix/eureka https://github.com/RestExpress/HyperExpress

This seems nice to have some tool augument the resources with links, but this makes me think, where does the logic to decide what links a resource should have belongs? In the service that exposes the resource? In the central service registry?

Answer 1

But in the microservice world, a service should have no knowledge of other services. AFAIK.

I think this is the root of your confusion. My understanding is that a service should not rely on out-of-band information to communicate with other services, for the purpose of software development. This means a service should not know anything about the internals of its peers, but it doesn't make any sense to say it should have no knowledge of other services. This does not conflict with HATEOAS, in fact, they complement each other.

There's no problem with linking to other services. How else would you build a macroservice from microservices? There's a problem with relying on out-of-band information for that.

Answer 2

Mediation, Orchestration and Choreography of services is not limited to SOA but equally applies to Microservices architecture as well.

Meaning microservices can communicate with other microservices to pass on or to get some information. For example a microservice needs to depend on stateful datastore in the stack of containers as well. So it needs to know the API/interface for the (RESTFull) database..

HATEOAS primarily provides interfacing and communication design patterns so you are free from say fixed interface definition language like WSDL or Swagger.

While it is true that REST (HTTP) have become most famous that it sometimes taken as granted that microservice will serve as a REST API but this is not true.

The beauty of microservices is that they do not restrict you to one or two communication patterns, its independent. There is no standard.

For example reactive microservices emphasize to use the message driven communication pattern and become location transparent of each other. But this does not mean not knowing about the verbs & payloads of other microservices to pass on or to retrieve.

Similarly we can have HATEOAS based communication patterns built into our microservices architecture in order to be fully flexible for ever changing/upgrading microservices interfaces. But still in general you need to know the location of the microservice to communicate to. Therefore the service-discovery and the service registry patterns exist in the microservices wold; and they equally applied to HATEOAS architecture. Where our microservices container can live and die (scale out & down) depending on the load; our customers constantly need to know the active location of the microservice(s) to be consumed.