[not_kurt_godel]

I appreciate the conceptual analogy, but that's not really HATEOAS. HATEOAS would mean your browser/client would be entirely responsible for the presentation layer, in whatever form you desired, whether it's buttons or forms or pages or not even a GUI at all, such as a chat interface.

[tsimionescu]

The Web is not only true HATEOAS, it is in fact the motivating example for HATEOAS. Roy Fielding's paper that introduced the concept is exactly about the web, REST and HATEOAS are the architecture patterns that he introduces primarily to guide the design of HTTP for the WWW.

The concept of a HATEOAS API is also very simple: the API is defined by a communication protocol, 1 endpoint, and a series of well-defined media types. For a website, the protocol is HTTP, that 1 endpoint is /index.html, and the media types are text/html, application/javascript, image/jpeg, application/json and all of the others.

The purpose of this system is to allow the creation of clients and servers completely independently of each other, and to allow the protocols to evolve independently in subsets of clients and servers without losing interoperability. This is perfectly achieved on the web, to an almost incredible degree. There has never been, at least not in the last decades, a big where, say, Firefox can't correctly display pages severed by Microsoft IIS: every browser really works with every web server, and no browser or server dev even feels a great need to explicitly test against the others.

[not_kurt_godel]

It's a broader definition of HATEOAS. A stricter interpretation with practical, real-world benefits is a RESTful API definition that is fully self-contained that the client can get in a single request from the server and construct the presentation layer in whole with no further information except server responses in the same format. Or, slightly less strictly, a system where the server procedurally generates the presentation layer from the same API definition, rather than requiring separate frontend code for the client.

[tsimionescu]

It is the original definition from Roy Fielding's paper. Arguably, you are talking about a more specific notion than the full breadth of what the HATEOAS concept was meant to inform.

The point of HATEOAS is to inform the architecture of any system that requires numerous clients and servers to interoperate with little ability for direct cooperation; and where you also need the ability to evolve this interaction in the longer term with the same constraint of no direct cooperation. As the dissertation explains, HATEOAS was used to guide specific fixes to correct mistakes in the HTTP/1.0 standard that limited the ability to achieve this goal for the WWW.

[alexpetros]

> HATEOAS would mean your browser/client would be entirely responsible for the presentation layer, in whatever form you desired, whether it's buttons or forms or pages or not even a GUI at all, such as a chat interface.

Browsers can alter a webpage with your chosen CSS, interactively read webpages out loud to you, or, as is the case with all the new AI browsers, provide LLM powered "answers" about a page's contents. These are all recontextualizations made possible by the universal HATEOAS interface of HTML.

[not_kurt_godel]

Altering the presentation layer is not the same thing as deriving it from a semantic API definition.

[alexpetros]

Altering the presentation layer is possible precisely because HTML is a semantic API definition: one broad enough to enable self-description across a variety of domains, but specific enough that those applications can still be re-contextualized according to the user's needs and preferences.

[not_kurt_godel]

Your point would be much stronger if all web forms were served in pure HTML and not 95% created by JS SPAs.

[sam_bristow]

I think the web itself would be stronger if it was served in pure HTML and not 95% created by JS SPAs.

[Descon]

That's a little picky, maybe it's HATEOAS + a little extra presentation sauce (the hottest HATEOAS extension!)

[not_kurt_godel]

It's not. The whole point of HATEOAS is that the presentation can be entirely derived from the API definition, full stop.

[alganet]

That is just wrong.

https://ics.uci.edu/~fielding/pubs/dissertation/net_arch_sty...

The server MUST be stateless, the client MAY be stateful. You can't get ETags and stuff like that without a stateful client.

[not_kurt_godel]

Deriving a presentation layer from an API definition has no bearing on whether the client has to be stateful or not. The key difference for 'true' HATEOAS is that the API schema is sufficiently descriptive that the client does not need to request any presentation layer; arguably not even HTML, but definitely not CSS or JavaScript.

https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_st...

> any concept that might be the target of an author's hypertext reference must fit within the definition of a resource

[alganet]

Dude, he literally mentions Java Applets as an example (it was popular back then, if it was written today it would have been JavaScript). It's all there. Section 5.1.7.

It's an optional constraint. It's valid for CSS, JavaScript and any kind of media type that is negotiable.

> resource: the intended conceptual target of a hypertext reference

> representation: HTML document, JPEG image

A resource is abstract. You always negotiate it, and receive a representation with a specific type. It's like an interface.

Therefore, `/style.css` is a resource. You can negotiate with clients if that resource is acceptable (using the Accept header).

"Presentation layer" is not even a concept for REST. You're trying to map framework-related ideas to REST, bumping into an impedance mismatch, and not realizing that the issue is in that mismatch, not REST itself.

REST is not responsible for people trying to make anemic APIs. They do it out of some sense of purity, but the demands do not come from HATEOAS. They come from other choices the designer made.

[not_kurt_godel]

I will concede the thrust of my argument probably does not fully align with Fielding's academic definition, so thank you for pointing me to that and explaining it a bit.

I'm realizing/remembering now that our internal working group's concept of HATEOAS was, apparently, much stricter to the point of being arguably divergent from Fielding's. For us "HATEOAS" became a flag in the ground for defining RESTful(ish) API schemas from which a user interface could be unambiguously derived and presented, in full with 100% functionality, with no HTML/CSS/JS, or at least only completely generic components and none specific to the particular schema.

[tsimionescu]

Yes, which is exactly true of the Web. There is no aspect of a web page that is not derived from the HTML+JS+CSS files served by a server.

[not_kurt_godel]

...which are a presentation layer and not a semantic, RESTful API definition.

[tsimionescu]

No, they are a semantic layer for the browser-server communication. They encapsulate human-readable content in a machine interpretable definition.

[ffsm8]

From what I read on wiki, I'm not sure what to think anymore - it does at least sound inline with the opinion that the current websites are actually HATeOAS.

I guess someone interested would have to read the original work by Roy (who seems to have come up with the term) to find out which opinion is true

[not_kurt_godel]

I worked on frontend projects and API designs directly related to trying to achieve HATEOAS, in a general, practical sense, for years. Browsing the modern web is not it.

[tsimionescu]

I think you are confusing the browser with the web page. You probably think that the Javascript code executed by your browser is part of the "client" in the REST architecture - which is simply not what we're talking about. When analyzing the WWW, the REST API interface is the interface between the web browser and the web server, i.e. the interface between, say, Safari and Apache. The web browser accesses a single endpoint on the server with no prior knowledge of what that endpoint represents, downloads a file from the server, analyzes the Content-Type, and can show the user what the server intends to show based on that Content-Type. The fact that one of these content types is a language for running server-controlled code doesn't influence this one bit.

The only thing that would have made the web not conform to HATEOAS were if browsers had to have code that's specific to, say, google.com, or maybe to Apache servers. The only example of anything like this on the modern web is the special log in integrations that Microsoft and Google added for their own web properties - that is indeed a break of the HATEOAS paradigm.

[not_kurt_godel]

I'm not confusing it. I was heavily motivated by business goals to find a general solution for HATEOAS-ifying API definitions. And yes, a web page, implemented in HTML/CSS/JS is a facsimile for it in a certain sense, but it's not self-contained RESTful API definition.

[tsimionescu]

Again, you're talking about a particular web page, when I'm talking about the entire World Wide Web. The API of the WWW is indeed a RESTful API, driven entirely by hyperlinks. You can consider the WWW as a single service in this sense, where there is a single, and your browser is a client of that service. The API of this service is described in the HTTP RFCs and the WHATWG living standard for HTML, and the ECMAScript standard.

Say I as a user want to read the latest news stories of the day in the NYT. I tell my browser to access the NYT website root address, and then it contacts the server and discovers all necessary information for achieving this task on its own. It may choose to present this information as a graphical web page, or as a stream of sound, all without knowing anything about the NYT web site a priori.