0

When using routing in a SPA web app (angular, react, etc), the user doesn't have to start at the entry point of the application. They can use a URL in the browser to drill down into any part of the application.

When implementing HATEOAS in a RESTful backend API, we assume that the front-end only knows the URL to the entry point of the API, and then the API provides links to other parts of the application from there.

So this begs the question, if a user enters a URL in the browser that loads a specific part of the SPA (not the entry point), how does the SPA get the appropriate API link needed for just that part of the SPA?

Does the SPA just make a bunch of API calls all at once, starting at the entry point of the API and following links until it gets the link it needs for the state it needs to load? And what happens when the API does not include the link needed because it's not a valid link based on the current state of the application?

HATEOAS doesn't seem to be very compatible with a modern SPA where you can load the application at very specific sections/states.

24
  • how does the SPA get the appropriate API link needed for just that part of the SPA? -- What? The SPA already has it; the user just typed it into the browser. – Robert Harvey May 8 '20 at 17:02
  • 1
    @RobertHarvey I think OP means the api(ajax) uri for a given page in a SPA – Esben Skov Pedersen May 8 '20 at 18:44
  • It obtains that URI the same way it always does. Typing a SPA URL into the browser by hand doesn't change that. – Robert Harvey May 8 '20 at 19:22
  • @RobertHarvey Yes it does... The point of HATEOAS is for the client to not have to know all of the API's URIs. The client app knows the URI to the entry point of the API, and then "discovers" and follows links from the entry point. If the web app doesn't start off at the entry point of the application, then they somehow have to get the API URI for any given part of the application, without the previous knowledge of all URIs in the API. If the client already knows every API URI up front, then it's defeating one of the main reasons to use HATEOAS in the first place. – wired_in May 8 '20 at 22:25
  • OK. So what do you suggest? Your assertion is that it can't be done. – Robert Harvey May 8 '20 at 22:26
1

When implementing HATEOAS in a RESTful backend API, we assume that the front-end only knows the URL to the entry point of the API, and then the API provides links to other parts of the application from there.

There might be some confusion here. The front-end (the client) may know only the entry point initially. As the user follows links and submits forms, i.e. navigates through state-changes, the user/client is completely free to "bookmark" (remember) any states in goes through, and can return to those states any time.

The concept of bookmarks, and returning to bookmarked states is completely compatible with REST and HATEOAS.

So obviously as the SPA changes state, it should always change the url to the appropriate state on the backend to reflect the state the frontend is in. This should always be possible, the SPA shouldn't have meaningful states that is not reflected on the backend! This also means if the user returns to this url, it will automatically return to the appropriate state on the backend too.

2
  • If I'm understanding correctly, you are suggesting that the SPA caches (bookmarks) the API URI for each state transition the first time the application is accessed from the entry point? What happens when the REST API changes a URI? After all, a key reason to use HATEOAS is because the URI is abstracted away. The client only needs to follow links given by the server, not know or understand the URI. The server should be free to change its URI if clients are simply requesting and following links based on the "rel" attribute. – wired_in May 8 '20 at 22:42
  • The SPA could cache all the state transitions, but that is a bit overkill. You are at some state, you only have to know the URL (or handful of URLs at most) of that state on the backend. If the URI changes, the server should provide redirects to the new URLs, and the client should update its state to the new URL on permanent redirect. – Robert Bräutigam May 9 '20 at 10:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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