SPA Routing with a RESTful API using HATEOAS

Question

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.

Answer 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.