Search code examples
resthateoas

How to manage HATEOAS links when the server is the client?

I'm learning about HATEOAS. The backend server I'm working on will use a third party REST API that uses HATEOAS. That API has an end point to return the url for each resource and also returns the related resource links with regular requests.

But I'm wondering what's a good way to manage these links on the server to avoid hardcoding them. For example if the third party changes the url of the resource, how will the server detect that change? Are there any standard practices for managing HATEOAS resource links?

Possible ways I can think of

  1. When the server starts, get all the resources urls and cache them. Whenever the third party API needs to be called, reuse these cached urls. Whenever there is a 404 or related error, update the resource url. Or update the url periodically in intervals.

  2. Get the resource url each time before calling the end point. Simplest but essentially doubles the number of requests.

But neither sound like robust ways.

Solution

  • While discovery is generally a good thing and should allow a HATEOAS system to introduce changes in ways that 'hardcoded urls' don't, if urls start breaking arbitrarily I would still consider this a major issue.

    You should be able to store urls / links on your side and have some expectation that those keep working.

    There are some mechanisms that deal with changes though:

    1. The server should return 301 / 308 redirects if a resource moved. If this were the case, you should also update your references.
    2. The server can emit Sunset or Deprecated headers. See: https://www.rfc-editor.org/rfc/rfc8594

    Those are more general answers, but ultimately the existence of best practices does not mean that vendors will abide by them. With that in mind I think your best bet is to try and find out what the deprecation policy is of your vendor and see what they recommend.