"An HTTP GET request includes request header fields and no payload body and is therefore transmitted as a single HEADERS frame, followed by zero or more CONTINUATION frames containing the serialized block of request header fields."
"A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request."
I've never used one or spec'd one, I consider it unsafe.
This is, of course, what the specs say, and they don't even really agree; I am well aware of the non-trivial daylight between "what the specs say" and "what happens in the real world". I point this out not as a spec compliance maniac but as something people ought to know... it's not a great plan to expect GETs to be able to have bodies, just as I would not suggest sending a 404 response code that also has the "real data" in it for whatever reason. You're just asking for trouble, even if it might sometimes work.
There's no reason for you to hold that opinion so strongly.
There's nothing inherently wrong with having a 200 for everything with a standard body structure, and there's nothing wrong with having a GET request with a body.
Where things go off the rails is strictly adhering to a specific thing without understanding the advantages and disadvantages of other approaches.
The angst around GET verbs is that someone could really be doing an update if it has a body. Well guess what, someone can be doing an update based purely off the query string too.
This angst around GET bodies is rules lawering AT BEST. It's the type of distinction that has no real merit and I consider it an absolutely short-sighted decision by the OpenAPI Spec to insist that GET has no body (they've recently changed this, but I can't believe it was ever a thing. Finally some common sense).
---
TO BE VERY CLEAR:
Back in the day you would hear stories of companies getting entire sets of data wiped out from a search engine bot that was happily following GET requests that would delete data.
There is absolutely nothing in a GET request that guarantees anything except what the developer decides to guarantee. That a developer SHOULD choose that a GET request be idempotent is still a choice regardless of the existence of a body or not.
I agree with you for the most part. Like I said, I consider it too dangerous to use, not that it's somehow impossible. But the reason I consider it too dangerous isn't that it's a Violation of the Holy Spec... everything and everyone violates the spec, to a first approximation. The problem is that all the libraries in the world and middleboxes and everything else violate the spec in different ways, and allow/enable/afford their own set of violations that do not match.
If you spec an HTTP API as having a GET with a body ("because otherwise the query string will be too long" or something), I can virtually guarantee you that as soon as it is even slightly popular you're going to get "But I'm using this library over here in some language you've barely heard of and its author thinks GET can't have a body so it won't send it to you, plz hlp".
I wouldn't consider it safe to deliberately use in an API. Similarly, I once accidentally sent a real reply as a 404 response (just a plain ol' bug), and while I did of course fix it quickly in my API, the user on the other end didn't have a good option for just ignoring it and moving on in the meantime. Their HTTP library got really feisty about using the body of a 404 ... I think it was something like, you could read it as a bag of bytes but all the clever "let's automatically JSONify this" and stuff functionality in their framework wouldn't fire on a 404. This is why I mentioned that one. It is a bad idea to treat the content of a 404 response as anything other than an advisory response to a human, and even that has some funny characteristics based on browser screwiness over the years.
There's definitely violations of the spec safer to specify, and violations less safe to specify; they're not all created equal.
RFC 7231 has been obsoleted by RFC 9110 since June; and interestingly enough it says absolutely nothing explicit about whether body in a GET request is allowed or not.
"An HTTP GET request includes request header fields and no payload body and is therefore transmitted as a single HEADERS frame, followed by zero or more CONTINUATION frames containing the serialized block of request header fields."
https://www.rfc-editor.org/rfc/rfc7540#section-8.1.3 (HTTP/2.0)
"A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request."
https://www.rfc-editor.org/rfc/rfc7231#section-4.3.1 (HTTP/1.1)
I've never used one or spec'd one, I consider it unsafe.
This is, of course, what the specs say, and they don't even really agree; I am well aware of the non-trivial daylight between "what the specs say" and "what happens in the real world". I point this out not as a spec compliance maniac but as something people ought to know... it's not a great plan to expect GETs to be able to have bodies, just as I would not suggest sending a 404 response code that also has the "real data" in it for whatever reason. You're just asking for trouble, even if it might sometimes work.