[gbear605]

At this point I’m infamous in my company for complaining about how something should have been done with a QUERY verb but it hasn’t been approved yet.

The cases tend to look like this: - An endpoint was implemented as a GET endpoint, since it’s for getting data, with the search terms in the query parameters. The search term got too long, breaking a critical behavior in production environments. - An endpoint was implemented as a POST endpoint, despite it being an idempotent query for data, since the request body is too large to fit in query parameters. New employees repeatedly come in and are confused why it’s not a GET endpoint, or why it doesn’t modify anything.

[tempest_]

A POST could be viewed as creating a "search" which, once given an ID could be retrieved later with a GET.

I know this densest really work with ad-hock and cheap queries but it does for more expensive / report style ones.

[thayne]

Also cases where a GET makes more sense, but there is concern about sensitive data in query parameters getting exposed in logs, so POST is used instead.

[venturecruelty]

You can always configure your HTTP logger to not log query parameters.

[ghxst]

From a security perspective it is best to assume everything in a GET query is public, it's not always your server logs that you have to worry about, it could also be logs on the clients system (as an example).

[JodieBenitez]

And here I am, using JSON-RPC 1.0 over HTTP for internal APIs, skipping all these debates.

[idbehold]

You also miss out on standardized HTTP caching mechanisms since those don't work with POST requests.

[JodieBenitez]

We don't want this on our use case so it's fine.