Lets say that we are creating a Ticket processing system. Say there are two distinct bounded contexts within this domain. Cancelling a Ticket Changing a Ticket
From what I understand, those two can be two different microservices, without having to know each other. What a ticket to a Cancel service could be completely different from what a ticket is to a Change service.
From a REST API design perspective, i have read a lot about using hypermedia and letting client discover resources by including relevant operations as links within the REST response (Stefan Tilkov's Talk). If thats true, when my Change Service returns a response, it makes sense to include a link to Cancel Service, which the client can use to perform cancel. How can I achieve this when Cancel and Change are two different microservices, which are not aware of each other? Or are my bounded contexts wrong?
Are we losing these hypermedia linking capabilities (or does it become harder) when use microservices in general?
Thanks Kay
In HATEOAS URIs are discoverable (and not documented) so that they can be changed. That is, unless they are the very entry points into your system (Cool URIs, the only ones that can be hard-coded by clients) - and you shouldn't have too many of those if you want the ability to evolve the rest of your system's URI structure in the future. This is in fact one of the most useful features of REST.
For the remaining non-Cool URIs, they can be changed over time, and your API documentation should spell out the fact that they should be discovered at runtime through hypermedia traversal.
That being said, in your scenario that link would be a Cool URI, and not relative to the current API (because it may reside on a different machine/domain etc). Unless you're using some discovery tool, you're going to have to hardcode that link, and thus lose the benefit of discoverability.