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

131–140 of 393 posts

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

#131

Post by recursivedoubts »

codethief wrote: post #128
recursivedoubts wrote: post #47

Earlier quoted context omitted.

I am the author and I agree with most of what you are saying here, REST and HATEOAS are for humans: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h... I disagree that it isn't an API, but that's a definition quibble. It is probably more profitable to talk about RESTful systems rather than RESTful APIs, since people think API == machines talking.

> I disagree that it isn't an API, but that's a definition quibble. I don't understand: An API is an application programming interface, i.e. it is meant to be consumed by other programs. How does that go together with > REST and HATEOAS are for humans ? And how does that go together with the requirements of "no interpretation needed" and therefore "little coupling" between client and server that were mentioned in the…

A concrete action I would suggest is splitting your data API out from your hypermedia API:

https://htmx.org/essays/hypermedia-apis-vs-data-apis/

Use hypermedia (and, who would have guessed I'd recommend this? something like htmx) to build your web application.

Use GraphQL or whatever other nonRESTful technology fits best to build your data API.

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

#132

Post by recursivedoubts »

mercutio2 wrote: post #122
recursivedoubts wrote: post #47

Earlier quoted context omitted.

I am the author and I agree with most of what you are saying here, REST and HATEOAS are for humans: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h... I disagree that it isn't an API, but that's a definition quibble. It is probably more profitable to talk about RESTful systems rather than RESTful APIs, since people think API == machines talking.

You don’t mention Content-Type anywhere I could find in your post. I don’t think hypermedia is only for humans. You can totally do REST for computers. You’re just supposed to divide knowledge along Content-Type boundaries. It’s true people mostly don’t do this, but it works great when people bother to describe rich Content-Types.

I mention Content-Type in that I think that discussions around it have largely been a distraction from what I consider the core innovation of REST: the uniform interface.

I recognize that many of the few people who still talk about REST would disagree with me on that.

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

#133

Post by recursivedoubts »

masklinn wrote: post #36
Sohcahtoa82 wrote: post #34

Earlier quoted context omitted.

I wish I could upvote this 100 times. REST, in its most strict form, feels like it was designed for humans to directly interact with. But this is exceptionally rare. Access will nearly always be done programmatically, at which point a lot of the cruft of REST is unnecessary.

> REST, in its most strict form, feels like it was designed for humans to directly interact with. It was literally extracted from the browser’s interaction model so… kinda?

No post body was provided.

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

#134

Post by zmmmmm »

potamic wrote: post #2

Great article. Calling APIs RESTful because they return JSON has always been a peeve of mine. But here's the question though, why do APIs need to be RESTful? What is the need for a client to have no knowledge of the server, if the server can also provide logic that can run on the client. In some sense, one could argue that a service that provides both raw data and client logic to transform raw data to hypermedia, is…

> What is the need for a client to have no knowledge of the server, if the server can also provide logic that can run on the client

It's a measure of decoupling I think. If your client started out with no knowledge of the server and still managed to work, then it will still work even when the server is upgraded, restructured, etc etc.

Of course, having every client just started at the root URL and then navigate its way to what it needs by effectively spidering the server just aint practical in any meaningful sense. But in small ways and critical places it is still possible to follow this pattern, and to the extent you do, in return you get a level of decoupling that is a useful property to have.

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

#135

Post by dgudkov »

vgel wrote: post #109
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…

This is incorrect. There are plenty of machines that read the web: web scrapers, and they've fostered a diverse ecosystem of tools. Search engines, archival tools, ML dataset collection, browser extensions and more are able to work with hypertext because it's self-describing. A new site can pop up and Google can index it without knowing if it's a blog, forum, storefront, or some new genre of website that may be inven…

>Search engines, archival tools, ML dataset collection, browser extensions and more are able to work with hypertext because it's self-describing

They only read state but never modify it. So it misses the whole point of interaction with a web resource.

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

#136

Post by icedchai »

russellbeattie wrote: post #97
ocimbote wrote: post #9

I feel old for I have witnessed many of these battles. But I feel that I have seen history. There's nothing wrong in this article, in the sense that everything's correct and right. But it is an old person's battle (figuratively, no offense to the author intended, I'm that old person sometimes). It would be like your grandparents correcting today's authors on their grammar. You may be right historically and normativel…

Articles like this are good to show how fads and buzzwords in tech take on a life of their own. Hopefully there are some younger devs in this thread who can learn from it. Us older guys have to do the opposite. As we see these things come and go, we get jaded and start to dismiss new techniques as fads. I shudder to think of how much wasted effort I put into "Enterprise JavaBeans" and "XSL Transforms". Years later, I…

You were right and wrong. Just because something is crap doesn't mean it won't stick around...

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

#137

Post by janci »

wwweston wrote: post #110
janci wrote: post #45

Because HATEOAS is stupid for client-server communication. It mandates discoverability of resources, but no sane client will go around and request random server-provided urls to discover what is available. On the other hand, it does not provide means to describe semantics of the resource properties, nor its data type or structure. So the client must have knowledge on the resources structure beforehand. Under HATEOAS…

> no sane client will go around and request random server-provided urls to discover what is available. "Random" isn't what's supposed to happen. You hit a top level endpoint, and then at that point other endpoints are made manifest, and then the UA/client and the user decide together what the next relevant endpoint is. And this is what happens all the time with the most common client (the browser). Seems to have work…

> You hit a top level endpoint, and then at that point other endpoints are made manifest, and then the UA/client and the user decide together what the next relevant endpoint is.

That's not how APIs are used. APIs consume and provide data. Raw data is unsuitable to be presented to the user. That's why HTML has so many formatting options. Formatting information is completely missing from APIs.

> Seems to have worked more or less for 30 years.

Yes, worked for good old web. In this sense, true REST is nothing new and even seems backwards. If we try to do REST while keeping data and presentation separate, we will come to something very similar to XML for data + XSLT for formatting. Or XForms. Old ideas all over again.

> I don't understand that, actually. Markup is underrated for data exchange potential these days.

XML/markup does not map well to basic data types in current programming languages. These work with strings, ints, floats and arrays/dictionaries thereof. Not Nodes, Elements and attributes of unknown/variant data types.

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

#138

Post by NonNefarious »

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…

EXACTLY. Regurgitators of the HATEOAS mantra never address this. Instead you get statements like one in this article: "the HTML response "carries along" all the API information necessary to continue interacting with the system directly within itself."

No, it doesn't. It's a list of URLs, which doesn't even indicate what operations they accept. The only thing REST supports, according to this philosophy, is a user manually traipsing through the "API" by clicking on stuff.

Thanks for summing it up so succinctly; I thought maybe I was missing something.

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

#139

Post by NonNefarious »

vgel wrote: post #109
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…

This is incorrect. There are plenty of machines that read the web: web scrapers, and they've fostered a diverse ecosystem of tools. Search engines, archival tools, ML dataset collection, browser extensions and more are able to work with hypertext because it's self-describing. A new site can pop up and Google can index it without knowing if it's a blog, forum, storefront, or some new genre of website that may be inven…

Web-scraping is not an example of published-API usage. Invalid comparison.

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

#140

Post by mixmastamyk »

greenthrow wrote: post #107

We all decided to keep the important principles of REST and drop the HTML responses because HTML is a terrible format for data exchange between automated systems. JSON is much better for this because it has a simpler schema. This post is very pedantic. Being pedantic is not helpful.

It starts describing how we got here. While if one reads to the end says, "it's fine."
Post reply on HN