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

251–260 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#251

Post by phamilton »

I think we should focus less on API schemas and more on just copying how browsers work.

Some examples:

It should be far more common for http clients to have well supported and heavily used Cookie jar implementations.

We should lean on Accept headers much more, especially with multiple mime-types and/or wildcards.

Http clients should have caching plugins to automatically respect caching headers.

There are many more examples. I've seen so much of HTTP reimplemented on top of itself over the years, often with poor results. Let's stop doing that. And when all our clients are doing those parts right, I suspect our APIs will get cleaner too.

Re: Most RESTful APIs aren't really RESTful

#252

Post by Balooga »

TekMol wrote: post #38
Scarblac wrote: post #31

Earlier quoted context omitted.

Bots, browsers that preload URLs, caching (both browser and backend and everything in between), the whole infrastructure of the Web that assumes GET never mutates and is always safe to repeat or serve from cache. Using GET also circumvents browser security stuff like CORS, because again the browser assumes GET never mutates.

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

Then that does not conform to the HTTP spec. GET endpoints must be safe, idempotent, cachable. Opening up a site to cases were web crawlers/scrapers may wreak havoc.

Re: Most RESTful APIs aren't really RESTful

#253

Post by wpm »

Xenoamorphous wrote: post #137
OJFord wrote: post #87

Earlier quoted context omitted.

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

Isn't that fairly straightforward? PUT for full updates and PATCH for partial ones. Does anybody do anything different?

You sweet summer child.

Re: Most RESTful APIs aren't really RESTful

#254

Post by kamranjon »

I am wondering if anyone can resolve this misunderstanding of REST for me…

If the backend provides a _links map which contains “orders” for example in the list - doesn’t the front end need to still understand what that key represents? Is there another piece I am missing that would actually decouple the front end from the backend?

Re: Most RESTful APIs aren't really RESTful

#255

Post by recursivedoubts »

ehutch79 wrote: post #248
recursivedoubts wrote: post #168

Earlier quoted context omitted.

Yes. You used it to enter this comment. I am using it to enter this reply. The magical client that can make use of an auto-discoverable API is called a "web browser", which you are using right this moment, as we speak.

So, given a hateos api, and stock firefox (or chrome, or safari, or whatever), it will generate client views with crud functionality? Let alone ux affordances, branding, etc.

Yes. You used such an api to post your reply. And I am using it as well, via the affordances presented by the mobile safari hypermedia client program. Quite an amazing system!

Re: Most RESTful APIs aren't really RESTful

#256

Post by recursivedoubts »

didntcheck wrote: post #231
recursivedoubts wrote: post #168

Earlier quoted context omitted.

Yes. You used it to enter this comment. I am using it to enter this reply. The magical client that can make use of an auto-discoverable API is called a "web browser", which you are using right this moment, as we speak.

The web browser is just following direct commands. The auto discovery and logic is implemented by my human brain

Yes.

https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

Re: Most RESTful APIs aren't really RESTful

#257

Post by troupo »

tgv wrote: post #159
lucideer wrote: post #129

Earlier quoted context omitted.

> - CRUD actions are mapped to POST/GET/PUT/DELETE Agree on your other three but I've seen far too many "REST APIs" with update, delete & even sometimes read operations behind a POST. "SOAP-style REST" I like to call it.

Do you care? From my point of view, post, put, delete, update, and patch all do the same. I would argue that if there is a difference, making the distinction in the url instead of the request method makes it easier to search code and log. And what's the correct verb anyway? So that's an argument that there may be too many request methods, but you could also argue there aren't enough. But then standardization becomes…

> From my point of view, post, put, delete, update, and patch all do the same.

That's how we got POST-only GraphQL.

In HTTP (and hence REST) these verbs have well-defined behaviour, including the very important things like idempotence and caching: https://github.com/for-GET/know-your-http-well/blob/master/m...

Re: Most RESTful APIs aren't really RESTful

#258

Post by kccqzy »

s_ting765 wrote: post #212
kccqzy wrote: post #171

Earlier quoted context omitted.

It's not just the original REST that usually has no benefits. The industry's reinterpreted version of weak REST also usually has little to no benefits. Who really cares that deleting a resource must necessarily be done with the DELETE HTTP verb rather than simply a POST?

The DELETE verb exists, there's no reason not to use it.

And you just added more work to yourself to interpret the HTTP verb. You already need work to interpret the body of a POST request, so why not put the information of "the operation is trying to delete" inside the body?

Re: Most RESTful APIs aren't really RESTful

#259

Post by marcosdumay »

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 really hate my conclusions here, but from a limited freedom point of view, if all of that is going to happen...

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

So we should better start with a standard scaffolding for the replies so we can encode the errors and forget about status codes. So the only thing generating an error status is unhandled exception mapped to 500. That's the one design that survives people disagreeing.

> There's a decent chance listing endpoints were changed to POST to support complex filters

So we'd better just standardize that lists support both GET and POST from the beginning. While you are there, also accept queries on both the url and body parameters.

Re: Most RESTful APIs aren't really RESTful

#260

Post by thom »

JimDabell wrote: post #196
thom wrote: post #183

Earlier quoted context omitted.

This is, almost canonically, the subject of Joel Spolsky's architecture astronauts essay.

It’s not. It’s pretty much the opposite. This is what he’s talking about: > our clever thinker invents a new, higher, broader abstraction > When you go too far up, abstraction-wise, you run out of oxygen. > They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line. REST is the opposite. REST is “We did this. It…

That's absolutely not what the essay is about. It's about the misassignment of credit for the success of a technology by people who think the minutiae of the clever implementation was important.
Post reply on HN