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