I'm considering HATEOAS for one of my application but for that, I need to be sure that it fits my needs. One of them is the ability to support direct links such as "https://www.webapp.com/user/1" for example. In this case, when the user lands on this page, the js code is supposed to fetch the user with ID 1. How am I supposed to do this with HATEOAS? Indeed, normally, I only know the root URL of the web service and I'm supposed to "discover" the other URLs but if the user clicks on this link in a mail, he will end up on the site that won't know the URL to the user web service.

Am I supposed to make a first request to retrieve some data about main URLs or something ?

  • 1
    I don’t really understand the problem. Is it about the base url of the API? The link In the email will point to a website that calls the API behind the scenes? Then the base url should be known on this website, for the user endpoint and all returned links in the user resource.
    – Rik D
    Aug 22, 2020 at 19:08
  • could you edit your question to make it more clear?
    – Rik D
    Aug 23, 2020 at 19:25
  • Doesn't the page already know the URL webapp.com/user/1 because that's the page's URL? Aug 24, 2020 at 16:48
  • This question is not only relevant, it is spot on, and represents a real problem. The fact that the question itself was downvoted shows that most people do not have any idea what HATEOAS is. The simple fact of the matter is, that while HATEOAS does solve a lot of problems, and seems great in theory, it is rarely used as intended in the real world.
    – wired_in
    Apr 6, 2021 at 18:36

3 Answers 3


From your comment:

...If the SPA is only supposed to know about the root URI of the web service and only knows that the user ID is "1", how is it supposed to know the route to the "user" endpoint...

HATEOAS applies to a resource and not to the entire API, so it’s fine for your SPA to know the Resources of the API. You should be able to do simple GET requests without first having to lookup which resources exist.

The links in the result of that GET requests are dependent on the state of the resource. For example an inactive Account could have links to Delete and Activate, while an active Account has links to Change Password and Inactivate. That’s where the power of HATEOAS is; static documentation lists four possible actions (activate, inactivate, delete, change password) but only two are valid depending on the current state. With HATEOAS the client needs less knowledge, because the server tells the client which actions are valid and the client can change it’s UI based on that.

  • This is wrong. Yes your SPA knows about the resources. It does not, however, know about the URL to each of those resources. The URL is supposed to be dynamic, and "discovered" through the links returned by the API, starting at the root of the API. The client knows about the "rel" attribute of each resource, which is a description, such as "users". The OP's question is spot on. This is a real problem, a compatibility issue between what we think of as a SPA and how HATEOAS is supposed to operate.
    – wired_in
    Apr 6, 2021 at 18:34

You just include the complete absolute url in an e-mail. That is an entry point to your app.

It's a fantastic example of HATEOAS, because it allows an unknown application (email client) to continue a workflow that began in your application, essentially carrying state of that interaction through time and space across unknown boundaries back home to your app.

Don't get stuck on some niggling bureaucratic implementation detail where someone says that if you include the base url in a link you are breaking the principle of HATEOAS. That's a detail of someone's implementation.

The principle is that you use the links you need to use to transfer application state wherever it needs to be transferred. HATEOAS does not have an official link format, and does not even dictate the use of http.

If you are providing links for use within your application's 'web pages' or spa 'views' it makes sense to use relative urls, removing a set of dependencies on infrastructure and network configuration from your app.

In a case like email you have no choice but to use the absolute and complete url in a form that's accessible from the internet.

  • 2
    This. I always like to say: "If you are wondering whether your URIs are ReSTful, they aren't, because ReST doesn't care what your URIs look like, and therefore, if you care what they look like, you are not doing ReST." This is a little strong, of course, because there are legitimate reasons to care what a URI looks like (readability, SEO, hackability, etc.) but the important point is: those have nothing to do with ReST. Aug 22, 2020 at 22:58
  • Maybe I was not totally clear. Say that the link is "web-app/user/1". This redirects the user to an SPA that needs to call an HATEOAS route with AJAX to get the user data. If the SPA is only supposed to know about the root URI of the web service and only knows that the user ID is "1", how is it supposed to know the route to the "user" endpoint (something like "web-app/api/user/1"? Either it has to do a call to get all the possible endpoints URL or it has to know the URL to the user one. Or am I missing something?
    – ssougnez
    Aug 23, 2020 at 19:14
  • This makes absolutely no sense at all. What are you even talking about? The URL in the email is a link to the client-side SPA application. It does not include the URL needed to call the backend API once you are inside the SPA. This is not a minor implementation detail of HATEOAS. HATEOAS is literally defined by discovering URL's through links sent back from the API. This means you don't know the URL to resources within the API ahead of time. So, you can't have a hardcoded URL that deep links into an SPA, since the SPA doesn't know the URL of the backend API resource ahead of time.
    – wired_in
    Apr 6, 2021 at 18:42
  • I feel like I'm in the twilight zone. The question, which is spot on has -1 votes, and the answer that misses the entire point of the question is the one with the most upvotes. Smh. How did you guys end up talking about the format of REST URL's? Where in the question is that even mentioned?
    – wired_in
    Apr 6, 2021 at 18:56

You cut to the heart of the problem with HATEOAS. If you know the endpoints you don't need the links.

It make no sense to include the links on every call vs having documention or a client. It's purely an academic idea of discoverablity without documentation which envisages an AI client or lost civilization.

  • You don’t think it can be useful to have different available actions depending on the state of the resource?
    – Rik D
    Aug 22, 2020 at 18:29
  • well.S is for Stateless,but the point is that you don't need to be told more than once what the link to perform an action is
    – Ewan
    Aug 22, 2020 at 18:42
  • 'Purely Academic' goes a bit too far. Discoverability without documentation works great for humans (e.g. this site). Including links allows a UI to achieve this same effect with minimal complexity and minimal dependency on service api details that may change. It's not needed everywhere, and in some use scenarios it feels awkward and redundant. But it is, at times, quite useful.
    – joshp
    Aug 22, 2020 at 18:57
  • Stateless means the server doesn’t keep state for each client (no sessions). Of course resources themselves have state. An API with HATEOAS tells the client which links are available depending on the state of the resource. I agree that static links on a resource are less useful, but they can still help to decouple the URL from the client (client has to know the link name in the API, which contains the URL).
    – Rik D
    Aug 22, 2020 at 18:57
  • guys im going to stand by my harsh opinion of HATEOAS. I just think if you follow things through to the end point of a user clicking a button or a program taking an action its redundant information. best case you waste some bandwidth, worst case links you cant deal with or lack of expected links cause runtime errors
    – Ewan
    Aug 22, 2020 at 19:01

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.