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

231–240 of 393 posts

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

#231

Post by sa46 »

twoodfin wrote: post #21

This article does a disservice to the benefits of “Richardson Maturity Level 2” i.e. “Use REST verbs”. A standard set of methods—with agreed upon semantics—is a huge architectural advantage over arbitrary “kingdom of nouns” RPC. I’d argue that by the time your API is consistently using URLs for all resources and HTTP verbs correctly for all methods to manipulate those resources, you’ve achieved tremendous gains over…

I'm on team RPC. I'll stay away from the term REST since my beef is with HTTP APIs that mix transport and application concerns.

- The Kingdom of Nouns comparison is forced. Yegge's complaint is that nouns own the verbs, meaning Java doesn't have first-class functions. The closest remote analog might be promise-pipelining which doesn't have much headway other than a single implementation for Cap-n-proto.

- RPC APIs are more consistent than an HTTP API. With HTTP, a unique method requires both a path and method, and if you're really unlucky, the method is polymorphic based on the contents of the request body.

- HTTP API requests can transport in different ways: request body, query parameters, HTTP path, and if you're really unlucky, headers.

Tremendous gains doesn't match my experience. The first step in using a HTTP API is to wrap it with an OpenAPI generator to build a consistent way to invoke the API, reinventing RPC client stubs in the process.

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

#232

Post by eastbound »

AtlasBarfed wrote: post #226
jonhohle wrote: post #218

Earlier quoted context omitted.

I’m not sure what the infatuation with HTTP verbs is. RPC allows modeling objects and arbitrary verbs. REST gives you a handful of verbs and punts on data modeling. It always seemed like a step back from an API design perspective. Definitely a battle I lost but never really understood the other side to begin with.

Standardization and a common language. Limits. Well developed error codes. Rpc is a huge footgun. What's annoying about rest is that it is a religion treated as a universal truth. But really, rest is basically crud.

However, anyone who has used HTTP error codes in REST knows to avoid that – Receiving a 404-Not-Found causes hours of debugging and blind poking compared to receiving a 200-OK-{“error”:”Entity not found”}…

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

#233

Post by kelseyfrog »

quickthrower2 wrote: post #216
kelseyfrog wrote: post #112

Earlier quoted context omitted.

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.

What do they do if they don’t hard code it? bookHotelUri = listHotelResponse.data.urls[4]; Or listHotelResponse .data.urls.find(u=>u.action===‘book’).url ?

Sort of. Verbs are still eschewed so rather than finding a 'book' link, it would be a 'booking' link to which a POST could be made to create a new booking. As a note, "Booking" is a confusing example because while a hotel booking is a noun it at first glance reads as a progressive tense verb.

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

#234

Post by kelseyfrog »

sanderjd wrote: post #198
kelseyfrog wrote: post #112

Earlier quoted context omitted.

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.

See, to me, this sounds like a failure to listen to your customer. They were telling you that well known URLs were useful to them, and you were forcing them to make more compromises so that you could make fewer.

We answered to the architecture team on matters of design. If the client team had had beef with the design, the client team took it up with them.

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

#235

Post by ackfoobar »

kragen wrote: post #215
recursivedoubts wrote: post #209

Earlier quoted context omitted.

2008 Fielding definitely wouldn't agree with me that HATEOAS is for humans. That's a conclusion I came to after watching it never catch on in the JSON API space and then trying to come up with an explanation as to why. I'd love to hear what he thinks of the idea. Thank you for the thoughtful comment!

Roy's suggestion in that comment thread is that it hasn't caught on because applying it takes more effort than people are willing to apply in most cases, in order to get benefits they don't care about, such as an architecture that can endure for decades (rather than, say, their OKRs for this quarter). I don't know if that's true, but it could be. It's also possible he's wrong about its benefits, or more precisely tha…

I see how one can argue that's why Haskell hasn't caught on, with the same line of reasoning. So I feel very comfortable dismissing it.

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

#237

Post by bigDinosaur »

eastbound wrote: post #232
AtlasBarfed wrote: post #226

Earlier quoted context omitted.

Standardization and a common language. Limits. Well developed error codes. Rpc is a huge footgun. What's annoying about rest is that it is a religion treated as a universal truth. But really, rest is basically crud.

However, anyone who has used HTTP error codes in REST knows to avoid that – Receiving a 404-Not-Found causes hours of debugging and blind poking compared to receiving a 200-OK-{“error”:”Entity not found”}…

Why can't you do a 404 + message?

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

#238

Post by vlovich123 »

mywittyname wrote: post #146
jaaron wrote: post #20

Earlier quoted context omitted.

> "This would suggest a restful api is not made for system-to-system communication, but requires human mediation at every step of the way" Which is exactly what REST was originally designed to do: provide an architecture for the Internet (not your app or service) that allows for humans using software clients to interact with services developed by programmers other than those which developed the clients. It was about…

People took the useful ideas and tossed the rest. The whole idea of embedding links into the data that describe available operations was not seen as useful, because most web pages already do that . That was not a problem that needed to be solved. But the concept of resource-oriented architectures which leveraged HTTP verbs to act on data with descriptive URIs was extremely useful in an era when interactions with web…

As someone who has implemented S3 (TL for Cloudflare R2) I’ll choose to disagree that the RESTfulness of the S3 API is a resounding success. Just go ahead and try to write the code to route requests. So many features are likely excluded just because Amazon couldn’t figure out how to jam it into HTTP verbiage.

So sure. S3 is implemented on top of REST but I’d much rather pick a proper RPC protocol. The only reason to stick with REST is that there’s an entire ecosystem around intercepting it as the lowest common denominator (proxies, reverse proxies, caching, browsers etc). If all of those spoke something more modern (gRPC, capnproto, etc) we might be better of. Certainly it would be simpler to maintain and evolve these code bases.

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

#239

Post by masklinn »

ninkendo wrote: post #174
masklinn wrote: post #36

Earlier quoted context omitted.

> 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?

But browsers already have HTML for this. Links are just tags. POST endpoints are exposed with , etc. Webpages. Why do we need a separate concept for this thing called REST if it just reduces to hypermedia in the end?

> Why do we need a separate concept for this thing called REST if it just reduces to hypermedia in the end?

Because REST is the formalisation of the interaction model. It was defined in a dissertation written about it. The very first section of the chapter is called “deriving REST”.

> But browsers already have HTML for this. Links are just tags. POST endpoints are exposed with , etc. Webpages.

HTML is not an interaction model, it’s a content-type (and one which assumes and requires human mediation).

REST was about formalising the underlying interaction model for machine contexts.

Post reply on HN