1

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.

Improve this question
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
    Commented May 8, 2020 at 17:02
  • 1
    @RobertHarvey I think OP means the api(ajax) uri for a given page in a SPA
    – Esben Skov Pedersen
    Commented May 8, 2020 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
    Commented May 8, 2020 at 19:22
  • 1
    Might I suggest that you don't actually need HATEOAS? HATEOAS is a discovery mechanism, intended to facilitate machine-to-machine document discovery and navigation. It probably doesn't apply to your application; you're only using it because it's the latest flavor of the week.
    – Robert Harvey
    Commented May 8, 2020 at 22:34
  • 1
    And it's not me that's saying this. You're saying it, in your own question: "HATEOAS doesn't seem to be very compatible with a modern SPA where you can load the application at very specific sections/states."
    – Robert Harvey
    Commented May 8, 2020 at 22:36

1 Answer 1

Reset to default
2

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.

Improve this answer
3
  • 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
    Commented May 8, 2020 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
    Commented May 9, 2020 at 10:18
  • That doesn't make sense... In order for a user to be able to bookmark any client URL, all backend URLs that correspond to the state at any given client URL need to be "cached". An SPA allows navigating to anywhere within the app via a URL. Thus the SPA would need knowledge of every backend URL needed to load state at any given client URL. However, the REST API is not under any obligation to adhere to any interface based on URL, since HATEAOS abstracts away the URL. So none of this is really compatible. Sounds like you are just trying to make it fit when it really doesn't.
    – wired_in
    Commented Apr 6, 2021 at 18:00

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.