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.

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.

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.