Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How did REST come to mean the opposite of REST?

htmx.org

Post reply on HN
Print view View original

111–120 of 393 posts

Re: How did REST come to mean the opposite of REST?

#111

Post by dvt »

This post tries to clarify things, but it's extremely confused and kinda' wrong. First, REST is a type of (distributed) architecture and really has nothing to do with how data is sent over the wire (as long as it's "hypermedia"). The claim that RESTful state has to be transferred via HTML is plain wrong[1].

Second, a JSON response is simply that: a bunch of data in JSON format. It is not JSON-RPC. JSON-RPC, unlike REST, is a protocol -- a way a client talks to a server -- and it usually looks like this:

    --> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
     {"jsonrpc": "2.0", "method": "subtract", "params": [23, 42], "id": 2}
XML-RPC is the same thing, but done with XML instead of JSON.

> The entire networking model of the application moved over to the JSON RPC style.

No, it didn't. Well, actually, I don't know exactly what "networking model" means in this case. Pretty sure we're still using TCP/IP. But I think it means the data-layer protocol; this is, however, still wrong. We're actually using HTTP methods (also known as RESTful verbs[2]) along with a JSON data format. This is still quite screwed up in the grand scheme of things, but in different ways than the article argues.

[1] According to the man himself, in fact: https://restfulapi.net/

[2] A terribly confusing term

Re: How did REST come to mean the opposite of REST?

#112

Post by kelseyfrog »

fennecfoxen wrote: post #78
kelseyfrog wrote: post #66

An earnest answer? Because few people have taken the couple hours(?) and read Roy Fielding's dissertation from start to finish. The biggest likely reason for not doing so is that frankly a bunch of people simply don't care, and why should they. There's very little incentive to do so. In fact, the fewer people that do, the less of an incentive there is - there is no one can call them out on it and they can reap the re…

I tend to find it helpful to ask, "is this proper REST as in HATEOAS, or is just 'REST-ish'?" It's usually just REST-ish: predefined URL patterns, roughly 1:1 with specific resource-APIs; they care about your HTTP verb and return JSON (but usually not with a lot of URLs in that JSON).

It's funny because HATEOAS violations were single-handedly the most common violation made by the client team during my time there. They loved hard coding URLs and willfully ignoring hypermedia.

Re: How did REST come to mean the opposite of REST?

#113

Post by SilasX »

recursivedoubts wrote: post #108
SilasX wrote: post #104

Earlier quoted context omitted.

That feels like a pretty significant quibble. API stands for “application programming interface”. If you cannot write an application to programmatically interface with it, why would you call it an API? What you and the parent see REST as, should be called an HPAI: “human-poking-around interface”.

REST is an application programming interface for RESTful systems, interpreted by RESTful clients (browsers). Generic Data APIs, and the clients that use them, are different and have different needs.

>REST is an application programming interface for RESTful systems, interpreted by RESTful clients (browsers).

No, the interpretation is done by the human using the browser, which is what makes it not programmable against, violating the P in the acronym.

Re: How did REST come to mean the opposite of REST?

#114

Post by ahepp »

I'm walking away from this article unable to find a really good reason to implement HATEOAS in an API meant to be consumed by a program (as Application Programming Interfaces typically are).

The best I can come up with (and this is me trying to like it) is that I guess the API is somewhat self documenting?

I see benefits to resource orientation and statelessness, but why do people get so upset about these APIs not following HATEOAS? Is it just a form of pedantry, that it's not really a REST API, it's a sparkling JSON-RPC?

Re: How did REST come to mean the opposite of REST?

#116

Post by geenat »

It may be time to re-visit this approach now that HTML5 is fully matured.

HTML5 was only just released in 2014, and took many years to be fully supported by major browsers.

At the time of JSON vs HTML, HTML was not yet in a standard place yet (XML API implementations were extremely inconsistent).

Fast forward to 2022, fetching and is an elegant pattern, and probably the way to go for self documenting API in the future!

Re: How did REST come to mean the opposite of REST?

#118

Post by wwweston »

Joeri wrote: post #7

The client knows nothing about the API end points associated with this data, except via URLs and hypermedia controls (links and forms) discoverable within the HTML itself. If the state of the resource changes such that the allowable actions available on that resource change (for example, if the account goes into overdraft) then the HTML response would change to show the new set of actions available. If the client kno…

> If the client knows nothing about the meaning of the responses, it cannot do anything with them but show them to a human for interpretation.

This is the best counterpoint in this discussion and it deserves a lot of reflection.

But that reflection should include the realization that this is what the browser does all the time. Browsers don't have any particular semantic model in their head of what any particular form action or hyperlink "means" in terms of domain logic... but they do have some semantics for broad classes of verbs and other interactions associated with markup-represented potential actions, and so they serve as an agent presenting these to the user who does whatever wetware does in processing domain semantics and logic and makes a choice.

This has worked so well over the last 30 years it's been the biggest platform ever.

We're now in territory where we're creating software that's almost alarmingly good at doing some semantic processing out of no particular structure. The idea that we're facing a dead end in terms of potential for clients to automatically get anything out of a hypertext API seems pretty tenuous to me.

Re: How did REST come to mean the opposite of REST?

#119

Post by femto113 »

There are two fundamental reasons HATEOS just doesn't work in practice. The first is that most services can't easily or reliably know their own absolute URLs , and HATEOS (and the behavior of many HTTP libraries) is inconsistent around relative URLs, so hacky and unmaintainable response rewriting gets applied at various levels. The second is that if you are diligently following a convention for how paths are constructed it's utterly redundant information--you can simply synthesize any path you need more easily than you can grok it out of HATEOS. The reasonable bits of REST that are left are not just HTTP verbs and JSON, but significantly the use of entity type names and ids in the path portion of the URL rather than in query parameters.

Re: How did REST come to mean the opposite of REST?

#120

Post by recursivedoubts »

rrauenza wrote: post #62

I feel like the author has conflated hypertext with html. The REST interface should be self describing, but that can be done in JSON. If you go to Roy Fielding's post... there is a comment where someone asks for clarification, and he responds: > When I say hypertext, I mean the simultaneous presentation of information and controls such that the information becomes the affordance through which the user (or automaton)…

No, I haven't. JSON can be used as a hypermedia, and people have tried this, but it hasn't really worked out very much and the industry trend is against it, towards a more RPC-like approach.

I'm using HTML as an example to demonstrate the uniform interface constraint of REST, and showing how this particular JSON (and, I claim with confidence, most extent JSON APIs) do not have a uniform interface. Which is fine: the uniform interface hasn't turned out to be as useful when it is consumed by code rather than humans.

There are good examples of successful non-HTML hypermedias. One of my favorites is hyperview, a mobile hypermedia:

https://hyperview.org/

Post reply on HN