Own, everyone own¹. The body is an attribute of an abstraction superior to the requisite entity; that is, every HTTP request is, like every HTTP response, a HTTP message and every message can be made up of start line headers and body.
HTTP-message = start-line
*( header-field CRLF )
CRLF
[ message-body ]
In fact, the only thing that sets a request apart from a response is just the start line .
In addition, in RFC 7231, which is the most current specification, when defining the GET , does not mention that it has no body; on the contrary, it brings the following quote:
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.
That in free translation, it would be that the load (body) of a GET request has no defined semantics; a GET request with body content may eventually be rejected in some implementations. So, if your application needs a body in a GET request, there is nothing wrong.
A simple case to visualize is to imagine that you have a route that brings the products sold in a virtual store:
/produtos
And you want to implement filters, so that you can select which products to return.
/produtos?data_cadastro.de=2018-05-01&data_cadastro.ate=2018-05-05
/produtos?preco.ate=100
/produtos?condicao=novo,usado
/produtos?possui_garantia=1
/produtos?nome.contem=camiseta
/produtos?frete_gratis=1
And a hundred other possible filters. Imagine the size of the URL to load so much information like this? For simplicity, you could very well pass all the information through the request body.
The same thing happens with the DELETE method, although much less often, since you would hardly have such complexity in deleting a resource, but if necessary, there is no problem at all.
(1): All methods have a body, including HEAD, however, by definition, any content in your body should be ignored by the server when generating the HTTP response.