If the queries are that long (over 2k-ish bytes), wouldn’t you wanna write a query file with POST and then execute it by name with a GET?

Then you need to build infrastructure for storing queries. Depending in the specifics of the project, that may or may not be OK.

That takes two steps, needs authorization, and needs queries created that way to be stable so that when you execute them with GET you know what you're executing.

This is a lot of application logic to add just to avoid adding a QUERY method. It's just too much.

while that could be preferred, here's some reasons why it may not be

1. pre-existing behavior. maybe queries have only started getting big enough to where this mattered, but all of our existing clients communicate the original way and won't migrate

2. more complex behavior on clients and services as you've now introduced a new stateful resource between client and service. should clients store query ids, or does the service handle idempotency? what db does the service use to store queries? how do we limit stored queries? do clients have to manage number of queries stored? does the service?

and you just re-invented stored procedures and/or RPC

pretty much the same pro's and con's too

safer, more controlled, better optimized but it's more limiting, another dev dependency and a responsibility bottleneck