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?

Erine

Why does the strictness of an architecture has to affect your functionality or business rules? I think both design patterns can co-exist. You'll always get dependencies between your services. – Nosography

Please check the answer in this question: #27791405 – Shaitan

While there are some nice info in that link, doesn't this just make a big monolith out of the whole thing at an information level? there needs to be some global registry that knows what resources belong together. – Erine

"In computing, microservices is a software architecture design pattern, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs.[1] These services are small, highly decoupled and focus on doing a small task." according to wikipedia. I can't see the "they can never link to anything else than themselves" part here. Where is it? en.wikipedia.org/wiki/Microservices (I guess the client can do the communication between microservices, but I don't really know the topic.) – Peloria

"link to anything else than themselves, which would pretty much be a Self link." - no, it won't. you can choose any link relation you want as long as it makes sense from client perspective. btw. I doubt that microservices must support only a single resource and a single method. but I guess I misunderstood the "self" in this case, and you weren't talking about a link relation. In this case you can interconnect you microservices in the clients or I guess in an upper layer. (aka layered architecture), but I still don't know anything about microservices. :D – Peloria

martinfowler.com/articles/microservices.html "microservices aim to be as decoupled and as cohesive as possible" if a service have to know of the existence of other services, I interpret that as they are no longer decoupled. there is a hard coupling in terms of linking. by moving/removing or changing the API of one service you affect the links another service have to apply to its resources. – Erine

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.

Lower

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.

Togoland