| ▲ | zahlman 5 hours ago | ||||||||||||||||||||||
Enabling the GET implementation to "accept the request body" would literally be the opposite of fixing it. The broken thing here is your expectation. You are looking for POST (or possibly PUT). | |||||||||||||||||||||||
| ▲ | elendilm 5 hours ago | parent | next [-] | ||||||||||||||||||||||
You would be surprised how many technologies expect GET with a body. In practical backend engineering, tools like Elasticsearch, GraphQL, complex query engines, and legacy internal APIs rely on GET with a body every day. Apparently even axios messes up on curl GET requests with a body as mentioned in the associated github issue. Perhaps the broken thing might be how you expect existing softwares to break so that your expectation can be satisfied. You should look at GET more closely. There is a reason curl allows to send GET requests with a body. There is a reason node allows to receive GET requests with a body. | |||||||||||||||||||||||
| |||||||||||||||||||||||
| ▲ | ButlerianJihad 5 hours ago | parent | prev [-] | ||||||||||||||||||||||
It was funny a few years ago, when I had to grade students answering a quiz about web services. There was a question about which components were necessary for a valid GET request. The required answer was a list of 4-5 components, such as the "GET" verb, the URI, the HTTP version, etc. And it was rather controversial that some listed a body as necessary for a GET request, and doing my research I came to find out that a "request body" was often quite undesirable and perhaps contrary to the RFC standards, and sending a "body" in a GET could result in undefined or unpredictable behavior. But it's all in good fun. | |||||||||||||||||||||||