5 ms·
I was referring to something like this. Here's a hypermedia API entry point I googled up. GET / { "version": "1.2.3", "description": "Example API to
by beachy 5y ago
I was referring to something like this.
Here's a hypermedia API entry point I googled up.
GET /
{
"version": "1.2.3",
"description": "Example API to manage orders",
"links": [
{ "rel": "orders", "href": "/orders" },
{ "rel": "customers", "href": "/customers"},
{ "rel": "customer-by-id", "href": "/customer/{id}"},
{ "rel": "customer-by-email", "href": "/customer{?email}"},
...
]
}
My point was, how is such an API served up when it spans resources that are managed by two separate services / microservices - one for customers, one for orders?
Of course this is a simple example, we are smart tech heads, so obviously we can wedge a third service in front of the other two, which exists solely to provide aggregating behavior like this.
But why? Is hypermedia so useful that it's worth going to this trouble? (No IMHO).
- eyelidlessness 5y agoDjango REST Framework (and I’m assuming later work by its authors) get this right and literally populate URLs rather than giving you patterns.
- beachy 5y agoNot familiar with Django sadly but it sounds like it would act as something of a proxy that sits in front of your microservices. My point is that if you are starting with just e.g 2 microservices, one for customers, one for orders, then hypermedia on it's own is not useful enough to justify adding a new proxy/ layer, just so that an API produced by one of those microservices can include hypermedia for the other.
- eyelidlessness 5y agoIt’s just providing a Uniform Resource Identifier. Doesn’t say anything about how you micro your services.
- nmadden 5y agoDon’t you just return links that refer to the other service? (ie absolute URLs). That is kind of the point of hyperlinks: the service hosting a resource can change, and you just change the links you serve rather than changing lots of hard-coded clients.
- beachy 5y ago(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.
- nmadden 5y agoWhy 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.
- beachy 5y agoThe 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.
- nmadden 5y agoWell 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.
- incrudible 5y ago> Is hypermedia so useful that it's worth going to this trouble? No. It's a pointless indirection. These APIs are universally awful to use. I'd also rather you provide a library that abstracts your poor taste in HTTP API design. If I have to navigate your HATEOAS swamp, you better make up for it by being really important (PayPal).