Probably not clear but I was talking about a situation where an API client (e.g a web application server) needs to manipulate customers (managed in one microservice) and also their orders (managed in another).
Not the two microservices talking to each other.
So the API client will be making separate API calls to each of the microservices.
My premise is that it is too hard for API responses from the customer microservice (for example) to include hypermedia links to resources within the orders microservice.
Got you. I just want to point out the absurdity of it. Java microservices commonly use Javascript Object Notation for their data transfer. How is that the right tool for the job. With all the translations that are needed, why don't they use RMI/RPC? And why even spend all that development time on something that you can solve in an afternoon with a JDBC connection anyway.
Because the paradigm of RPC is not about data transfer (which is the serialization protocol).
RPC is one architectural style. It's pretty undefined other than "call/response". Marshalling of arguments is just a serialization issue.
RMI/RPC doesn't work well across firewalls or org boundaries. It doesn't support separating internal and external host identification, so when you try to RMI to a host in another DNS ___domain that has a local name, there's all sorts of nonsense to get the Java runtime to understand it can have multiple DNS names and be associated with multiple network interfaces.
JSON/protobuf/cap'nproto/ONC-XDR/XML are about serializing data (whether it's a resource or a marshalled argument/result for RPC).
So basically: it doesn't work well if you want to reach every IP on the whole internet. Yeah I suppose that's correct, but we are talking about internal service-to-service communication so why would you have those requirements in the first place?
It's only call/response because that's all you ever need if you can call any arbitrary function by it's name. That's infinitely more powerful than any other protocol that restricts you to a limited grammar.
>Probably not clear but I was talking about a situation where an API client (e.g a web application server) needs to manipulate customers (managed in one microservice) and also their orders (managed in another).
I would use a microservice gateway with the client only talking to the gateway. It seems weird to me that the client can call any microservice.
