Live data from Hacker News

Most RESTful APIs aren't really RESTful

florian-kraemer.net

571–580 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#571
post #159

Earlier quoted context omitted.

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…

> Do you care? I don't. I could deliver a diatribe on how even the common arguments for differentiating GET & POST don't hold water. HEAD is the only verb with any mild use in the base spec. On the other hand: > correct status codes and at least a few are used contrary to the HTTP spec This is a bigger problem than verb choice & something I very much care about.

There's one, though. The client can tell the server it has a cached version, but that only works (automatically) for GET in browsers. That could have been solved without resorting to those verbs, of course, but it's legacy.

HEAD allows the server to send meta data without the (potentially very large) body. That could have been solved without verb (as if HEAD is a verb in this case!), of course, but it has its uses.

Re: Most RESTful APIs aren't really RESTful

#572
post #15

Earlier quoted context omitted.

> Only GETs should include a querystring. Why?

Because HTTP is a lot more sophisticated than anyone cares to acknowledge. The entire premise of "REST", as it is academically defined, is an oversimplification of how any non-trivial API would actually work. The only good part is the notion of "state transfer".

What does that have to do with query parameters in non-GET requests?

Re: Most RESTful APIs aren't really RESTful

#573

Earlier quoted context omitted.

XMLHttpRequest? fetch? We're talking JSON APIs -- HTML forms are incompatible with that no matter the verb.

Fetch came in around 2015, and XMLHttpRequest wasn't consistent in the way different verbs were handled, like redirects, as this blog post[0] from 2006 points out: > Basic redirect support is pretty universal, but things quickly fall apart on most browsers when you do tricky things like use non-GET/POST methods on redirecting resources. There were other things too, I'm not sure CORS supported anything but GET and POS…

> I've long ago caved to the reality of the web's limited support for most of the other verbs.

Sounds like this reality is not the recent one.

Re: Most RESTful APIs aren't really RESTful

#574

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 inclusion of HATEAOS links which are NEVER used

Re: Most RESTful APIs aren't really RESTful

#576

Earlier quoted context omitted.

> So then one gets to bike-shed if "signup" it is in the request path, query parameters, or the body. But that's not a difference between /user/signup and /user:signup .

That's correct, the example you are giving represents bike-shedding among request path variations. I assumed most readers of my comment would get that the idea that /users/signup is ambiguous whether or not that is supposed to be another resource, while /users:signup is less so.

It's not ambiguous that api/users/signup refers to a resource. One of the constraints of REST is that endpoints refer to resources.

Re: Most RESTful APIs aren't really RESTful

#577
post #193

Earlier quoted context omitted.

the last point got me. How can you idiomatically do a read only request with complex filters? For me both PUT and POST are "writable" operations, while "GET" are assumed to be read only. However, if you need to encode the state of the UI (filters or whatnot), it's preferred to use JSON rather than query params (which have length limitations). So ... how does one do it?

If you really want this idiomatically correct, put the data in JSON or other suitable format, zip it and encode in Base64 to pass via GET as a single parameter. To hit the browser limits you will need so big query that you may hit UX constraints earlier in many cases (2048 bytes is 50+ UUIDs or 100+ polygon points etc). Pros: the search query is a link that can be shared, the result can be cached. Cons: harder to deb…

Cons: not postman or cURL friendly.

Re: Most RESTful APIs aren't really RESTful

#579
A few years ago I spent an unreasonable amount of time creating a RESTful API design guide for my employer. The goal was to standardize the way APIs would be created for all systems. We argued over HATEOAS, true REST with hypermedia, custom media types, status codes etc.

We ended up with what I consider to be a solid design guide rooted in the correct use of Web standards. Not REST but RESTful. Clear and understandable, uniform, etc.

At the end of the day though the real challenge was more to make people adhere to those conventions. Why? Because most developers don't care at all. They want to finish their "Agile" sprint on time. They don't care about architecture, correctness, enterprise-wide homogeneity etc. Beyond the lack of ONE actual standard, that's the other real major problem.

https://github.com/NationalBankBelgium/REST-API-Design-Guide...

Post reply on HN