0

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?

Stanislav Bashkyrtsev
  • 159
  • 1
    abandon hateos.. oh wait.. "except" – Ewan Dec 12 '21 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. – Filip Milovanović Dec 12 '21 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? – Stanislav Bashkyrtsev Dec 12 '21 at 11:47

1 Answers1

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.

Ewan
  • 75,506
  • 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. – Stanislav Bashkyrtsev Dec 12 '21 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 '21 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 '21 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. – Stanislav Bashkyrtsev Dec 12 '21 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 '21 at 10:10
  • if the consumer knows the url pattern, then you might as well get rid of the hateoas links all togther and just have a normal client – Ewan Dec 13 '21 at 10:12