如何在分布式REST服务体系结构中生成HATEOAS链接？

Question

I'm new to REST and doing a lot of research right now to consider migrating an internal monolithic service architecture to something leaner and more distributed. I'm having a bit of trouble wrapping my head around how to generate HATEOAS links for resources in a distributed microservice system. I understand generally why you shouldn't store the relations themselves in the database, but the alternative is to generate them in code.

If one of the primary benefits of microservices is that they allow distinct teams to work independently to improve their service and APIs, how can one team reliably generate links to another team's service resources? Is this just a matter of keeping an eye on breaking changes in your APIs and then versioning them appropriately so that other teams can update their resource links whenever they choose?

If so, is it really best to just hardcode links? It seems to me that there must be some sort of best practice for how to do this, I'm just new enough to the scene that I must not be finding the right search terms.

Thanks for any help!

Answer 1

I haven't had the opportunity to implement a REST API using HATEOAS, but I had some time to think of how I would implement it.

The most interesting way I thought of would be to implement a sort of "DNS server "for REST APIs, which would basically construct the urls to the different REST APIs available on your system.

This "DNS" type service would expose a operation like:

GET /apis/{resourceTypeIdentifier}/{resourceIdentifier}

Which would in turn return the url where the resource could be consumed.

Example:

Your API (let's say an offer API) needs to return a reference to a resource that is outside of its domain (let's say a customer with id 001). To obtain the link to the external resource it will call the DNS api like so:

GET /apis/offer/001

Which would return an url from where someone could fetch the rest of the information about that resource (eg, https://www.example.org/myofferapi/v3/offers/001 or https://www.example.org/myofferapi/v3/offers?offerId=001 ). The service could return an url as complex as is needed as long as the api of this DNS is implemented in generic way.

It would then be the responsibility of the API owners to update the "DNS" database with the information that the "DNS" API needs in order to construct the urls. This would take out the responsibility of keeping track and updating the url on each of the consumers and instead put it solely on the service provider.