[8cvor6j844qw_d6]

For the experienced devs. May I ask why would one use POST for everything?

I encountered a codebase with only POST for all operations, given my lack of knowledge in this area, I am not sure why one would choose POST only over the standard set of GET, PUT, POST, DELETE, etc.

[nhumrich]

I prefer POST for everything. The main reason why is because HTTP verbs don't match cleanly to every operation. And it leads to a lot of bike shedding around the exceptions. POST for everything, on the other hand, forces you to put the "method" in the request outside of HTTP semantics, which allows you to "just use" whatever verb makes sense rather than trying to map it to the limited ones available.

[gaigalas]

GET: I want to see stuff.

POST: I want to change stuff.

I don't know how this style cannot match cleanly any architecture.

It's not supposed to be a map to CRUD, it's a bunch of building blocks for manipulating state over a network.

[themafia]

PATCH: I want to change stuff.

[gaigalas]

PATCH: I want to change stuff in a predictable way.

--

PUT: I want to replace stuff.

DELETE: I don't want anyone to GET that stuff anymore.

HEAD: I want to peak at how stuff is shown.

OPTIONS: I want to know what I can do with stuff.

--

COPY: I want to copy stuff (WebDav)

MOVE: I want to move stuff (WebDav)

MKCOL: I want a new sublevel of stuff (WebDav)

PROPFIND: I want to list stuff (WebDav)

PROPPATCH: I want to mass change stuff (WebDav)

LOCK: I want to control who METHODs stuff.

UNLOCK: I want to remove control over who METHODs stuff.

--

All of those are actually optional. It is okay to use POST[0]. GET and POST with proper hypermedia (media types and links) is all 99% of apps need.

[0]: https://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post

[Zambyte]

What if the stuff you want to see can't be encoded in a URL?

[gaigalas]

I'm assuming the case here is lots of query params. Stuff like `?foo=bar&lorem=ipsum...`.

Most likely, you would benefit from making a cirurgical mini-resource on the server.

Introduce `/report/{id}`, and make it into a POST.

The user POSTs to `/report`, and the answer is 201 (Created) or 202 (Accepted), with a `Location: /report/123` (generated short id). The thing you changed on the server, is that now that long list have a short id. Just that.

Then, the user `GET /report/123` (auto redirect). It all happens within the same socket (keep-alive) and it has almost zero overhead (one refresh without this probably has thousands of times more overhead than the redirect).

By doing that, it seems that you are wasting stuff, but you're not.

Now the user doesn't have to transfer huge amounts of query data when GETing the results again, cache layers will have an easier time, and you can even use that mini-resource as a shortcut to solve things like racing conditions (two users doing the same humongous query at the same time).

Realistically, unless you're some query-by-image type of thing (trying to search images that match an existing one), you'll never actually have to face URL limits. If you are one of those cases, then you probably already have other architectural constraints that would justify introducing the extra intermediate resource.

[8cvor6j844qw_d6]

Hmm... sort of like an intermediate page?

That would explain a some of the design decisions. I had to do work on a old codebase and am studying it.

Thank you and the others too for the input.

[zvrba]

Because with POST you have a RPC (remote procedure call) with arbitrary semantics and HTTPS is just a convenient transport.

That's also why I only use a couple of status codes: Ok, Created, NoContent, BadRequest, Forbidden, Unauthorized an InternalServerError (the latter two generated automatically by the framework).

GET, PUT, DELTE, etc. seem to be tailored towards entities, but as soon as the endpoint is not an "entity", the semantics get vague and break down.

[LudwigNagasena]

Consistency, simplicity, RPC semantics.

[RedShift1]

The default for GraphQL queries is POST so maybe they were using that.

[iberator]

It was safer in some sense before TLS. No data in URL.

[julianlam]

If you encounter a shop that uses POST for everything then they are probably a shop that doesn't know that verbs other than GET and POST exist.

... and they don't use GET everywhere because one time Google scraped that endpoint and dropped the production database.