I have my system which receives data from another service and then I show the data to my users. I'd like to store an ID or a link to the data. Then UI will go for the data using the ID/link.

If we were to use HATEOAS, we'd go with links, so:

  1. Poll the data from that service
  2. Store links to the resources
  3. When UI opens - it gets the links from my DB and follows those links

But if service location changes or the URL format changes - we get broken links. Of course we can go with hacks like nginx URL rewrite, but this isn't pretty. Anyone has a good solution except for abandoning HATEOAS in this case?

  • 1
    abandon hateos.. oh wait.. "except"
    – Ewan
    Dec 12, 2021 at 11:38
  • 2
    What you're describing is not HATEOAS, because you're storing links. HATEOAS is: there's one public "entry point" link, that gives you a page with possible actions/other links, and all navigation is done that way; if the links change, you just return pages with different links. But that's the original conception of REST, where HATEOAS was a means to solve a specific problem, and was central to the architectural style. What the industry calls RESTful services doesn't use HATEOAS anyway, so don't worry about it. Dec 12, 2021 at 11:43
  • @FilipMilovanović, right, but your "entry point" scenario implies that we walk over the graph of resources using links. And we don't construct the resources URLs ourselves. Now in addition to that I have a requirement to reference one of the resources (store the ref in DB). Since I chose to use HATEAOAS for my primary scenario - I have to live with this. And some how accommodate the scenario with long-term storage of refs to resources. Any solutions to that? Dec 12, 2021 at 11:47

1 Answer 1


TBH this isn't a HATEOAS issue, its just simple backwards compatibility or version management.

If you release a backward incompatible version of your api, one does not simply decommission the previous version. You have to keep it up and route the old version traffic to it with for example header or path routing.

Once the v-Old traffic drops to zero, then you can turn it off. This requires that you reach out to your consumers and get them to upgrade their systems.

  • Suppose you keep backward compatibility for 6 months. Now in case when I store IDs - I simply change the configuration of my service and it generates URLs differently now. No problem at all. In case when I store links I have to update DB state (parse out IDs from URLs and generate new URLs). Both scenarios will leverage backward compatibility. But HATEOAS scenario is still a problem. Dec 12, 2021 at 11:51
  • That seems unreliable, you would have no guarentee that the urls would be convertable. as a consumer I would have to re do whatever calls I originally used to get the links and overwrite the saved version
    – Ewan
    Dec 12, 2021 at 12:26
  • i mean thinking about it you dont really have any guarantee HATEOAS links will remain valid even without any change in version. saving them isnt a good idea
    – Ewan
    Dec 12, 2021 at 12:28
  • Yep.. In which case our HATEOAS API must provide the IDs. And our client will have to know about the URL format. Which breaks some of the ideas of HATEOAS. Though maybe we could at least have some endpoint in that service which returns something like: "getDogPattern": https://some.server.com/dog/{id}. We could poll it once a day. This could allow the service to keep evolving w/o breaking the clients. Dec 12, 2021 at 13:16
  • you are assuming the api provides a get by id endpoint in the new version. How you deal with the change depends on the nature of the change, but the common factor is you need to update the consuming code
    – Ewan
    Dec 13, 2021 at 10:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.