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

Most RESTful APIs aren't really RESTful

florian-kraemer.net

Post reply on HN
Print view View original

81–90 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#81

Post by hnfong »

delusional wrote: post #69
cjpearson wrote: post #40

I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…

Importantly for the discussion, this also doesn't mean the push for REST api's was a failure. Sure, we didn't end up with what was precisely envisioned from that paper, but we still got a whole lot better than CORBA and SOAP. The lowest common denominator in the REST world is a lot better than the lowest common denominator in SOAP world, but you have to convince the technically literate and ideological bunch first.

We still have gRPC though...

Re: Most RESTful APIs aren't really RESTful

#82

Post by pantulis »

cjpearson wrote: post #40

I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…

> The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec

I had to chuckle here. So true!

Re: Most RESTful APIs aren't really RESTful

#83

Post by TekMol »

Scarblac wrote: post #75
TekMol wrote: post #38

Earlier quoted context omitted.

So why is there no problem with vote/flag/vouche on HN being GET endpoints?

There is, it's bad. Luckily votes aren't very crucial.

Votes are crucial. HN goes to great lengths to prevent votes that do not stem from real user intent.

See this post for example:

https://news.ycombinator.com/item?id=22761897

Quotes:

"Voting ring detection has been one of HN's priorities for over 12 years"

"I've personally spent hundreds of hours working on this"

Re: Most RESTful APIs aren't really RESTful

#84

Post by skrebbel »

cjpearson wrote: post #40

I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…

Hell yeah. IMO we should collectively get over ourselves and just agree that what you describe is the true, proper, present-day meaning of "REST API".

Re: Most RESTful APIs aren't really RESTful

#86

Post by pradn »

mixedbit wrote: post #47

When I was working on my first HTTP-based API 13 years ago, based on many comments about true REST, I decided to first study what REST should really be. I've read Fielding's paper cover to cover, I've read RESTful Web Services Cookbook from O'Reilly and then proceeded to workaround Django idioms to provide REST API. This was a bit cargo cult thinking from my end, I didn't truly understand how REST would benefit my se…

I think you're right. APIs have a lot of aspects to them, so describing them is hard. API users need to know typical latency bounds, which error codes may be retried, whether an action is atomic or idempotent. HATEOAS gets you none of these things.

So fully implementing a perfect version of REST is usually not necessary for most types of problems users actually encounter.

What REST has given us is an industry-wide lingua franca. At the basic level, it's a basic understanding of how to map nouns/verbs to HTTP verbs and URLs. Users get to use the basic HTTP response codes. There's still a ton of design and subtlety to all this. Do you really get to do things that are technically allowed, but might break at a typical load balancer (returning bodies with certain error codes)? Is your returning 500 retriable in all cases, with what preferred backoff behavior?

Re: Most RESTful APIs aren't really RESTful

#87

Post by OJFord »

cjpearson wrote: post #40

I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…

> I can safely assume [...] CRUD actions are mapped to POST/GET/PUT/DELETE

Not totally sure about that - I think you need to check what they decided about PUT vs PATCH.

Re: Most RESTful APIs aren't really RESTful

#88

Post by dingi »

At some point, we built REST clients so generic they could handle nearly any use case. Honestly, building truly RESTful APIs has been easy for ages, just render HTML on the server and send it to the browser. That's 100% REST with no fuss.

The irony is, when people try to implement "pure REST" (as in Level 3 of the Richardson Maturity Model with HATEOAS), they often end up reinventing a worse version of a web browser. So it's no surprise that most developers stop at Level 2—using proper HTTP verbs and resource-based URIs. Full REST just isn't worth the complexity in most real-world applications.

Re: Most RESTful APIs aren't really RESTful

#89

Post by mort96 »

blueflow wrote: post #67
mort96 wrote: post #54

Earlier quoted context omitted.

I disagree. It's a perfectly fine approach to many kinds of APIs, and people aren't "mediocre" just for using widely accepted words to describe this approach to designing HTTP APIs.

> and people aren't "mediocre" just for using widely accepted words If you work off "widely accepted words" when there is disagreeing primary literature, you are probably mediocre.

So your view is that the person who coins a term forever has full rights to dictate the meaning of that term, regardless of what meaning turns out to be useful in practice and gets broadly accepted by the community? And you think that anyone who disagrees with such an ultra-prescriptivist view of linguistics is somehow a "mediocre programmer"? Do I have that right?

Re: Most RESTful APIs aren't really RESTful

#90

Post by liendolucas »

https://htmx.org/img/memes/dbtohtml.png

LMAO all companies asking for extensive REST API design/implementation experience in their job requirements, along with the lastest hot frontend frameworks.

I should probably fire back by asking if they know what they're asking for, because I'm pretty sure they don't.

Post reply on HN