I'm very happy about this proposal. The only sad thing is that it has come so late, after so many tools and protocols (e.g. GraphQL) already abuse POSTs for this use case.
I agree. It takes me back arguments I had with my PM when I worked for a small SaaS close to 10 years ago. I had to use POST for a query API because of the limitations around GET & URL encoding of the parameters for the exact reasons outlined in TFA. She insisted it be a GET until I showed real, existing client queries that couldn't be handled. Only then, did she relent. Same PM also insisted I send results of queries as a list of objects in JSON, instead of a more compact tabular format, because tables aren't REST-y. I lost that battle, and the serialized results of queries were an order of magnitude larger than they needed to be...
> She insisted it be a GET until I showed real, existing client queries that couldn't be handled... Same PM also insisted I send results of queries as a list of objects in JSON, instead of a more compact tabular format, because tables aren't REST-y.
I think I'm on the side of the PM with this one on both counts. You sound like someone who really cares about efficiency, performance, and edge cases -- a proper engineer. But PMs are supposed to bring us down to earth and say that simplicity and maintainability are more important than saving bytes and to not waste time fixing things that aren't broken.
In a past life I spent so much effort optimizing our stack to lower our AWS bill until a PM sat me down with the company's finances and showed me the teeeeny little bar that was our cloud expenses and then legitimately 20x taller bar that was salaries and basically said that spending money to buy back my or my team's time was more important.
