Talk:HATEOAS

Origin / merge discussion

Perhaps this should be merged into the REST article?

I don't know who wrote the above, but personally I don't agree. However, it should be noted somewhere that the concept is not mentioned in Fielding's thesis. It never occurs at all. After reading the thesis and the article I have no idea where it came from. It's not mentioned in the blog posting referred to, either. --LarsMarius (talk) 21:32, 20 May 2011 (UTC)

The blog post says "What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?" - ok it doesnt use the acronym, but seems pretty clear. I wouldnt have any objection to a merge into REST. Justinc (talk) 11:22, 21 May 2011 (UTC)

I added a ref to the origin in the Fielding dissertation. HATEOAS itself is never mentioned, but hypermedia as the engine of application state appears on page 82. Avindratalk 20:14, 5 September 2023 (UTC)

Link relations that make up a fixed interface

"In this way, RESTful interaction is driven by hypermedia, rather than out-of-band information." The source used to support this statement allows "spend[ing] descriptive effort [...] in defining extended relation names". But wouldn't a set of such "extended relation names" make up "a fixed interface shared through documentation", which the lead says is characteristic of a service-oriented architecture? --Damian Yerrick (talk | stalk) 15:28, 11 July 2012 (UTC)

No; Fielding is saying that REST APIs should present navigational / interface disclosure interactively, and exclusively in-band. A good term paper is self-explanatory, and doesn't need an accompanying oral presentation; a good website explicitly and contextually provides links and functionality to the user, without requiring a separate reference guide. So it is for a HATEOAS-constrained REST API; otherwise you're just using an RPC with an HTTP wrapper. (RPCs, in contrast, are very particular in their usage, and if you don't know exactly what you're doing, you're not going anywhere; hence the documentation.) Razordaze (talk) 22:58, 13 September 2015 (UTC)

2 Cents from some one else -- — Preceding unsigned comment added by 24.22.50.89 (talk) 01:35, 12 January 2014 (UTC) This article appears to bogus. It has next to no sources and does not seem to relate to topics discussed in single referenced source. If their was a mark this as spam article I would.

Verb based resources?

The <link> resource names are verbs. This is counter to RESTful guidelines, is it not? -> Yes, in my opinion this page is corrupted. REST is about resources and not about operations. 2001:8D8:1FE:700:0:0:1:3 (talk) 16:41, 10 June 2015 (UTC)

<link> in this context is not a verb, it's just markup to denote an existing location (noun). The server isn't doing anything when it provides that information; it's not related to the LINK / UNLINK HTTP methods of RFC2068. Here's another source that explains HATEOAS a bit more clearly: http://blog.codecentric.de/en/2012/11/a-restful-learning-curve-nouns-verbs-hateoas-and-roca/ Razordaze (talk) 23:16, 13 September 2015 (UTC)

The original point still stands (it wasn't about "link" at all, and the point is backed up by the linked article. "close" in "/accounts/12345/close" is not a noun but a verb, and "deposit" in ""/accounts/12345/deposit" is a verb not a noun, unlike "deposits" in "/accounts/12345/deposits". REST being about resources, nouns, not actions, verbs.

https://htmx.org/essays/hateoas/ would agree 81.187.169.133 (talk) 16:17, 22 April 2022 (UTC)

Pronunciation

How is HATEOAS supposed to be pronounced? I always pronounced it HATE-O-AS but I think it should be HAT-E-OAS (rhymes with Adiós?). Found https://www.howtopronounce.com/hateoas/

I don't know but I think it's probably the weirdest looking acronym I've seen. It sounds like Cheerios except with hate instead of cheer. :D — Preceding unsigned comment added by 205.172.134.23 (talk) 20:17, 21 August 2015 (UTC)

I think both HAT-E-OAS and HATE-E-OAS are acceptable pronunciations. I've heard both repeatedly over the years. In fact, at the API Strategy Conference a few weeks ago, I won a box of "Honey Nut HATEOAS" in a contest. There's a picture on my post here: http://clarify.io/blog/api-strategy-conference-2015-recap/ Either way, that makes it an acronym instead of an abbreviation. Caseydk (talk) 07:13, 8 December 2015 (UTC)

if so better would be citing both (I agree it would be useful) Lrkwz (talk) 23:44, 1 March 2023 (UTC)

Origin

Who came up with the acronym - it clearly wasn't necessary to preface it with the word HATE. The minter of that one clearly doesn't realize that the powerfully negative suggestion it carries will kill it dead as people strive to avoid it instinctively. Slashdottir (talk) 17:29, 13 February 2016 (UTC)

That cheered me up, thanks! :) 92.2.131.104 (talk) 09:36, 13 July 2018 (UTC)

See first discussion on origin. Here are additional links which provide more context:

• https://roy.gbiv.com/talks/200709_fielding_rest.pdf
• https://www.w3.org/TR/2003/WD-ws-arch-20030808/
• https://www.mnot.net/blog/2007/02/27/rest_issues

The remaining issue: it's not clear when *HATEOAS* acronym was made. Avindratalk 20:42, 5 September 2023 (UTC)

The example is a JSON API, not really HATEOAS

I may be putting my hand into a wasp-nest here, but I have been reading a lot about the original intent of Hypermedia and HTML. What spurred this was the rapid growth of HTMX (currently in draft Draft:HTMX) which to a large extent takes us back to the roots of HATEOAS and Hypermedia. There are a lot of people who are more knowledgeable about HATEOAS than me, so I am reluctant to change the example unless other people agree that it is not HATEOAS, it is just a JSON API with some (but not all) of the characteristics of HATEOAS. There is a really good example of good HATEOAS here https://htmx.org/essays/hateoas/

HTTP/1.1 200 OK

<html>
  <body>
    <div>Account number: 12345</div>
    <div>Balance: $100.00 USD</div>
    <div>Links:
        <a href="/accounts/12345/deposits">deposits</a>
        <a href="/accounts/12345/withdrawals">withdrawals</a>
        <a href="/accounts/12345/transfers">transfers</a>
        <a href="/accounts/12345/close-requests">close-requests</a>
    </div>
  <body>
</html>

Do you agree? --CaliViking (talk) 20:49, 21 January 2024 (UTC)

Agree 2A02:8108:1200:768B:7C09:6C26:D476:AA9A (talk) 11:35, 10 July 2024 (UTC)

spam, Htmx does not belong here

HTML itself is hypermedia, with the <form>...</form> element in control of HTTP requests to links.[2][4] Htmx introduces extensions to HTML to allow elements other than <form>...</form> and <button>...</button> to control requests.

is spam — Preceding unsigned comment added by 2600:1700:E6B0:CD80:D324:55F5:CD8C:5DA9 (talk) 11:57, 23 November 2024 (UTC)

Agreeing on removing the mention of htmx, at least for now. Aside from the current version of the text being technically incorrect—htmx does not extend the HTML syntax, it just makes use of existing HTML syntax features like attributes—its mention here doesn't clarify what HATEOAS is or how HTML as a hypermedia can be used to satisfy the constraint.

@CaliViking proposes above that we switch the leading example from JSON to HTML, echoing the sentiments expressed by htmx maintainers. It is worth mentioning, however, that the example in the proposal is lifted directly from the htmx maintainers' own reworking of the HATEOAS article and aside from potential copyright problems (the text isn't labeled, but it should be CC BY-SA, assuming it's been modified from the JSON in Wikipedia's article), this veers a little into editing-by-proxy. They do note that their version is "more opinionated [...] than would be appropriate for Wikipedia".

All that said, I do think that an HTML is better than JSON as a hypermedia that can demonstrate HATEOAS as envisioned by Fielding, who explicitly names HTML as a resource representation in his original REST thesis. I would not mention htmx at all, except possibly as an example of how JavaScript can be used within HTML to augment in more HTTP verbs (see § 5.3.3 Data View from the above cite link). Ebucario (talk) 14:37, 3 April 2026 (UTC)