(the example I used is so simple it didn't really highlight the difficulty)
My point is that one microservice cannot easily generate links for another.
How does the customer microservice (that wants to be hypermediaful), generate a deep link into the order microservice, e.g perhaps to obtain the latest order for a customer?
It can't, unless it is uncomfortably tightly coupled to the other microservice.
The most pragmatic solution is not even to try. Better to pass on the hand wavey HATEOAS stuff, and just tell the developers to work from the API documentation.
> How does the customer microservice (that wants to be hypermediaful), generate a deep link into the order microservice, e.g perhaps to obtain the latest order for a customer?
In short, you're asking how to implement service discovery.
Also, in REST there is no such thing as a "deep link". There are only resources, and links to said resources. HATEOAS returns responses that represent application state by providing links to related resources, and that's pretty much all there is to it.
I completely agree it is in part a service discovery problem - my original point is that HATEOAS is not a workable service discovery mechanism in a microservices environment.
Instead, use some service discovery technology. Not hypermedia.
It's too hard for one service to generate links (yes, let's call them complex links instead of deep links for enhanced correctness) into another.
If it can do that then they were never really independent microservices in the first place, they are so tightly coupled.
> I completely agree it is in part a service discovery problem - my original point is that HATEOAS is not a workable service discovery mechanism in a microservices environment.
What leads you to believe that? You want a related resource, and you get it by checking it's location. It's service discovery moved to the resource level. What's hard about it?
> Instead, use some service discovery technology. Not hypermedia.
I don't understand what's your point. Where do you see any relevant difference? HATEOAS is already service discovery at the resource level.
> It's too hard for one service to generate links (yes, let's call them complex links instead of deep links for enhanced correctness) into another.
Not really. Tedious? Yes. Too hard? Absolutely not. Not only there are even modules and packages that either do that for you or do most of the work but also it's not different than just putting together a response to a request.
> If it can do that then they were never really independent microservices in the first place, they are so tightly coupled.
You seem very confused about this subject as you're not only mixing up unrelated concepts but also imagining problems where there are none.
From the start, REST is just an architectural style, and HATEOAS is just an element of said style. HATEOAS basically boils down to a technique to allow clients to not have hardcoded references to URLs pointing to resources. Instead, when you get a response to a request, the response also returns where you can find related resources. That's it. It matters nothing if said links never change at all during the life of a service. What it matters is that if you're developing a service that's consumed by third-parties that support HATEOAS, you do not have any problem whatsoever peeling out responsibilities to other services or even redeploying them anywhere else, because your clients will simply know where to look without requiring any code change at all.
> My point is that one microservice cannot easily generate links for another.
Right, if these are all REST services, then one service should not be generating links for another, it should be obtaining those links from the service itself.
> How does the customer microservice (that wants to be hypermediaful), generate a deep link into the order microservice, e.g perhaps to obtain the latest order for a customer?
It asks the service for a link via a call to a link it obtained from the service's stable entry point. Pretty standard stuff when you're reasoning about encapsulated systems.
Why do you think it’s hard for one microservice to generate links to another microservice? The alternative is that all the clients are tightly coupled to both of them.
The alternative may not be palatable to you but IMO if two microservices have an encyclopedic knowledge of each other's url structures, then they aren't really separate microservices at all.
Well indeed, but the hyperlinks here are just surfacing the coupling that already exists between those services. Making explicit an already implicit coupling.
Two other points:
- you can use HATEOAS to let one microservice discover the links it needs from another, exactly as a client would do.
- by not using hyperlinks you have not solved the problem, you’ve just moved the requirement to know the URL structure from another microservice (that you control) to dozens or hundreds of clients, that you likely don’t control. This makes your services much more brittle, not less.
Respectfully I believe you have constructed a straw man.
In this contrived example, assume there is no need for the customers microservice to even know about the existence of orders to do it's job.
So forcing it to understand all the various url formats, query params, that the orders microservice supports - just so it can populate hypermedia elements in it's own APIs - which in turn is being done only to support discoverable clients or perhaps to appease the REST gods - seems an ugly architectural choice to me.
Perhaps I would feel differently if I had ever seen a project where HATEOAS had really moved the needle instead of being more a catalyst for ideological battles.
Surely the Orders service would support a single entrypoint - "index for customer X", or something - which would return a list of links into the resources that it owns? You're not forcing the Customers service to know anything more than that single per-customer entrypoint.
Exactly the same pattern applies for any other domain. All the Customers service needs to know is that there is a link to another domain; the structure is entirely down to the service for the other domain to manage.
Why does the knowledge have to be encyclopaedic in the first place?
If a customer microservice has to link to another, the only information it needs is the link format, for example: `https://another-microservice/customers/{customer_id}/orders`. This URL pattern can be in an environment variable, or configuration file.
However, I'd consider needing a customer-related microservice to link to the "last order" in another microservice a bit excessive. Why is this requirement in place? Why can't the client go to the first URL (`/customers/{customer_id}/orders`) and figure the last order from another link there? The link to the last order can be provided by the second microservice, without needing to involve the customers microservice.
If this is all an optimisation to save the client a roundtrip, then yeah, there are gonna be downsides. But that's the nature of optimisations: there are downsides. It would be the same in any other architecture.
Parent commenter point is that you need the URL structure to be somewhere. If it's not in the microservices, it's in the frontends. There's no magic silver bullet here, something's gotta give...
My point is that one microservice cannot easily generate links for another.
How does the customer microservice (that wants to be hypermediaful), generate a deep link into the order microservice, e.g perhaps to obtain the latest order for a customer?
It can't, unless it is uncomfortably tightly coupled to the other microservice.
The most pragmatic solution is not even to try. Better to pass on the hand wavey HATEOAS stuff, and just tell the developers to work from the API documentation.