I've been sending request body along GET method for years now
Generally not a great idea. With some http implementations this is not even possible (for example, fetch)
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
> You cannot include a body with GET requests
And transparent caching might result in weird issues.
you can do all kinds of nonstandard stuff if you control the server, the client, and any steps in between. the point of standards is for when you don't control it all.
put your server behind a managed load balancer or a caching proxy, and your get requests with bodies aren't going to do so well anymore.
When it's your client talking to your server you can obviously do whatever you want - it doesn't cause problems until you want to involve third-party code, such as a reverse proxy (such as nginx) or a CDN. This includes proxies your customers may be using.
> "A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain."
"Content" is what the RFC calls a request body. The simplest argument against IMO is it makes caching more complex, as now the request body would have to be part of any cache keying etc, you can't just blindly key off the request + URI params for every single GET. There are plenty of other reasons to not do it.
The spec expects responses to GETs generally to be cacheable:
> "The response to a GET request is cacheable; a cache MAY use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (Section 5.2 of [CACHING])."
You've never heard of BEEP? Well, that's why.