Hacker News Reader

Comment by tgv | Hacker News Reader

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 an absolute mess.

So I say: GET or POST.

View on HN

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

Yeah but GET doesn’t allow requests to have bodies (yeah, I know, technically you can but it’s not very useful), and this is a legitimate issue preventing its use in complex APIs.

I've had situations when I wanted a GET with a body :) But not that many

There's no point in idempotency for operations that change the state. DELETE is supposed to be idempotent, but it can only be if you limit yourself to deletion by unique, non-repeating id. Should you do something like delete by email or product, you have to use another operation, which then obviously will be POST anyway. And there's no way to "cache" a delete operation.

It's just absurd to mention idempotency when the state gets altered.

> There's no point in idempotency for operations that change the state.

Of course there is

> DELETE is supposed to be idempotent, but it can only be if you limit yourself to deletion by unique, non-repeating id

Which is most operations

> Should you do something like delete by email or product, you have to use another operation,

Erm.... No, you don't?

> which then obviously will be POST anyway. And there's no way to "cache" a delete operation.

Why would you want to cache a delete operation?

The defined behaviors are not so well defined for more complex APIs.

You may have an API for example that updates one object and inserts another one, or even deletes an old resource and inserts a new one

The verbs are only very clear for very simple CRUD operations. There is a lot of nuance otherwise that you need documentation for and having to deal with these verbs both as the developer or user of an API is a nuisance with no real benefit

> The defined behaviors are not so well defined for more complex APIs.

They are. Your APIs can always be defined as a combination of "safe, idempotent, cacheable"

I've had situations when I wanted a GET with a body :)

I agree. From what I have seen in corporate settings, using anything more than GET/POST takes the time to deploy the API to a different level. Using UPDATE, PATCH etc. typically involves firewall changes that may take weeks or months to get approved and deployed followed a never ending audit/re-justification process.

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

Reply on news.ycombinator.com