3 ms·

Don’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 cha

Don’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 ago
  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.
  - beachy 5y ago
    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.
    - nmadden 5y ago
      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.
      - beachy 5y ago
        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.
        regularfry 5y ago
        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.
    - ratww 5y ago
      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 https://another-microservice/customers/{customer_id}/orders`. This URL pattern can be in an environment variable, or configuration file. -- As for your example, if you need the last order, you can have a link that performs a 302 redirect: `https://another-microservice/customers/{customer_id}/last-order https://another-microservice/customers/{customer_id}/last-or...`. Nothing wrong with redirects. 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...
- nuerow 5y ago
  > 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.
  - beachy 5y ago
    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.
    - nuerow 5y ago
      > 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.
- naasking 5y ago
  > 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.

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 ago
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.
- beachy 5y ago
  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.
  - nmadden 5y ago
    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.
    - beachy 5y ago
      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.
      - regularfry 5y ago
        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.
  - ratww 5y ago
    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 https://another-microservice/customers/{customer_id}/orders`. This URL pattern can be in an environment variable, or configuration file. -- As for your example, if you need the last order, you can have a link that performs a 302 redirect: `https://another-microservice/customers/{customer_id}/last-order https://another-microservice/customers/{customer_id}/last-or...`. Nothing wrong with redirects. 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...
nuerow 5y ago
> 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.
- beachy 5y ago
  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.
  - nuerow 5y ago
    > 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.
naasking 5y ago
> 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.