Hacker News Reader

Comment by lolinder | Hacker News Reader

If you read the article, it's pretty clear that they're not advocating using HATEOAS for a computer-consumable API—it's all HTML, meant to be rendered by a web browser and clicked on by the user. You could code a computer agent against this as well, but a hypermedia system is designed for users first.

View on HN

In that case your REST API is just a new name for web application and your API responses are just web pages.

Yes, that's essentially their point—REST started as a description of a good hypertext architecture and was coopted to describe just about any JSON API. HATEOAS only makes sense in the original context.

> In the early 2000s the concept of REST was appropriated from its initial conceptual environment as a description of the early web into other areas of web development

> Yes, that's essentially their point—REST started as a description of a good hypertext architecture and was coopted to describe just about any JSON API. HATEOAS only makes sense in the original context.

I don't think that your opinion is valid. What you refer as "JSON API" is actually just resources being represented with a specific JSON-based media type, in the same way that opening a page is actually a resource represented as a HTML-based media type. Some web scrapers are basically HATEOAS clients.

I believe the grandparent is making a valid point. It depends on implicit assumptions we have in mind reading it.

The way I'm reading your comment, that JSON-based (or XML-based, or some binary format-based for that matter) media type encodes hyperlinks in some form. Then the client is a simplified, specialized browser, if you will. But the mechanics of client/server interaction are essentially the same as a "traditional" web application (as in Django, RoR, PHP, etc).

And if it's a machine-to-machine interaction, the client is very simalar to a web crawler/scraper, although the media types it parses is not necessary HTML.

In other words, you are absolutely right in that REST is non confined to HTML.

What the grandparent means by JSON API, I think, is the kind of HTTP API we are used to see designed for mobile and SPA clients -- pretty URIs for endpoints, HTTP methods, JSON-serialized request/response bodies...

Those can actually be very nice API, pleasant to work with. It's just that it's not REST.

But at this point, it's probably more productive to go with the flow and just accept people refer to such API as REST.

That said, to me, understanding the difference is still valuable. Even if I'm not going to mention it out loud in a work setting.

Yes, exactly. The confusion (not unique on your part) comes from the notion that REST has something to do with the JSON/XML APIs that the term conjures up in your mind. Whoever said that's what it was supposed to mean? (Lots of people, I know. The point is, they're wrong.) REST is just how the Web works (or at least worked—at the time that Fielding wrote his dissertation).

jcrites explains it really well: <https://news.ycombinator.com/item?id=23672561>

The answer to your question, "has anyone ever made a non-toy implementation conforming to the idea of HATEOAS?", therefore, is "Yeah. Your Web browser."

Disabuse yourself of anything you have ever been told that has led you to believe REST is an alternative to (or a special flavor of) RPC. It's not about RPC.

Then I will have to read the thesis once more. Sigh. I am pretty sure it talks about APIs, that is interfaces consumable by software. What a browser does, formatting and rendering a response, is not what I would call consuming an API. Well, the browser is actually consuming an API, it sends URLs and receives HTML or whatever. Is that the API the thesis has in mind, HTTP itself, while I was always thinking about the one on top, the one that lets me transfer money from my account to someone else? In some ways that would make sense, in others not at all.

> "Is that the API the thesis has in mind, HTTP itself, while I was always thinking about the one on top, the one that lets me transfer money from my account to someone else?"

Yep, that's it.

Field's REST/HATEOAS can be used as a "layer" underneath a more traditional, schema-bound, RPC-like API. This is what Google did with GData, for example.

I don’t think that is a good explanation.

> REST is about describing services that you can interact with with no prior knowledge. REST is about completely decoupling the client and server (in terms of prior knowledge) beyond standardized media types (HTML, CSS, JS)

The idea that REST is confined to standard media types like HTML and CSS is wrong. It is sufficient that media types are known to specific clients and server, but that does not have to include web browsers or arbitrary clients.

Quote [1]:

REST provides a hybrid of all three options by focusing on a shared understanding of data types with metadata, but limiting the scope of what is revealed to a standardized interface. REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types, selected dynamically based on the capabilities or desires of the recipient and the nature of the resource. Whether the representation is in the same format as the raw source, or is derived from the source, remains hidden behind the interface. The benefits of the mobile object style are approximated by sending a representation that consists of instructions in the standard data format of an encapsulated rendering engine (e.g., Java [45]).

[1] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...

I don't get what your quibble is.

> The idea that REST is confined to standard media types[...] is wrong

You sourced the response yourself:

> REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types

... and given that you did just copy and paste that part, it leads me to believe that that's not what you've got an issue with. So what do you have an issue with?

„Standard media type” has different meaning in the comment you refer to and in the quote.

This is not a very helpful response.

You reference a comment that basically says that REST is HTML UI talking to server via links and forms, rather than interaction with JSON or XML-based API. This is not correct, neither according to original dissertation nor according to modern understanding of RMM 3 APIs. API using JSON can support HATEOAS. Standard media type in the sense of REST is not the W3C media type, but anything that both server and client can understand. appilcation/hal+json is a good example.

Nope. Try again. It "basically" says what it says—which is the same thing that the part you quoted from Fielding says—and nowhere does it say that the media type has to be HTML, which is what you (now) seem to be implying (but are unable or unwilling to articulate for some reason).

How exactly do you understand the following quote that is part of what you call a „good explanation“?

> REST is about completely decoupling the client and server (in terms of prior knowledge) beyond standardized media types (HTML, CSS, JS)

I understand it the way it's written. I don't know what you're looking for here; jcrites is not staying that { HTML, CSS, JS } are prerequisites to REST. They're giving examples of standard media types. If there are other media types for which it is possible to do REST, then those are acceptable, too, of course. But HTML is not a requirement.

The comment you're complaining about says "beyond standardized media types (HTML, CSS, JS)".

"Beyond" in this case means "not only".

You're absolutely correct in stating REST is not confined to HTML, CSS, JS. A JSON, XML, or binary-based media type are all compatible with the architectural style.

I don't think the grandparent implies otherwise, though. They are using the browser/HTML example to describe the particular mechanics of client/server interaction, which are key to a REST application.

They also bring up "decoupling the client and server (in terms of prior knowledge)". As far as I understand, this isn't about an ability of an arbitrary client to talk to the server.

This is, again, easier to explain using the web browser as an example, but the principle equally applies to any client. Think of a "traditional" web application (Django, RoR, etc).

Say, one day you decide to completely rewrite it -- add new pages, remove some existing pages, change the site structure (as in which pages the user can navigate to from a given page). While the app has changed beyond recognition, the user doesn't need to download a new version of browser, they can still point their existing browser to the app's home page and it will just work.

Now, all of the above should hold for a RESTful app based on a binary media type. I believe, this is the key point of going REST-way.

There's a trade-off, of course. While the client is decoupled from the server along one axis, they are fundamentally coupled along another. Imagine a RESTful banking app, and let's say we would like to add a list of recent transactions to the home screen of a mobile client, but the server resource representing the home screen doesn't encode this list in any way. Well, there's is no way to just add it on the client in this case, at least without breaking the principles of REST hence defying the whole purpose of choosing this architectural style in the first place. We have to change the backend code in this case.

I can readily see how the limitation described above might be a deal-breaker for a lot of apps as we know them today.

In that case what's the point of any of it? The user doesn't care about how your URLs are structured. They just read pages and click links, and anything below that is up to the programmer's preference

[Ed: correct] Caching.

> The user doesn't care about how your URLs are structured.

This sounds like you're still thinking that REST is supposed to mean what you thought it meant before (and that it somehow has something to do with "how your URLs are structured").

I'm struggling to glean any meaning out of multiple explanations of HATEOAS beyond "response bodies with hyperlinks in them". Whatever it is, it's too unstructured for computers to automatically use, and unnecessary for humans, who are quite capable of using, well, any website designed for a human

The phrase "hypermedia as the engine of application state" is something Fielding came up with when philosophizing about the architectural style of the Web circa 2000 and how it differed from other architectural styles. That's all it is. That it's "too unstructured for computers to automatically use" is not a failure case, because there was no objective other than to describe how the Web worked. He was developing a taxonomy—to guide how things should (continue to) work based on the world as it already is—not trying to invent something new and admonish people that "Hey, this is how we really ought to be doing things"—unlike the tone of many articles that you've probably read about the promises of this whole "REST" thing, right?

If you expect it to be anything else at this point, then you are sure to end up disappointed, because you are setting yourself up for failure by thinking that it's something that it's not. Kinda sucks that an entire industry misled you into thinking otherwise, but that is its wont...

Think of a "traditional" web application (Django, RoR, etc).

Now, if instead of such a web application we have one based on a binary media type instead of HTML and a custom client instead of the browser, but otherwise everything described above still apply, this is a RESTful app too.

If a decoupling like this is a priority for an app, REST is a good choice for it.

We have to change the backend code any time we want to change what's available on one of client screen's and where the user can navigate from that screen. This can be a deal-breaker limitation for a lot of apps. They're better off designed around another architectural style -- an API having pretty URIs for endpoints, JSON-serialized request/response bodies, utilizing HTTP method for CRUD operations is one such alternative.

> Whatever it is, it's too unstructured for computers to automatically use, and unnecessary for humans, who are quite capable of using, well, any website designed for a human

Another person posted a good answer to this part of your comment. But let me respond to it too.

"any website designed for a human" is an instance of REST/HATEOAS architecture by definition. Roy Fielding came up with the name to describe software systems organized exactly like this.

> it's too unstructured for computers to automatically use

Indeed. In my opinion, designing an app meant for automatic consumption by a computer in RESTful style is not a great idea.

Humans can just as easily read an OpenApi spec.

Reply on news.ycombinator.com