GET -> POST when user adds request body

[ashitaprasad]

Tell us about the task you want to perform and are unable to do so because the feature is not available
Automatically switch to POST method from GET when the user adds a request body. This feature will improve the user experience.
Also, show a message in the snackbar when this switch happens to notify the user.

[opxdelwin]

Hey @ashitaprasad , it is expected to go the other way around, i.e POST -> GET if request body is null?

[ashitaprasad]

No, it will not go the other way round, once switched from GET to POST.

[opxdelwin]

I'm writing a test case for the same, will create a PR soon 💪

[sebastianbuechler]

@ashitaprasad According to RFC having a body for GET is not forbidden: "Request message framing is independent of method semantics, even if the method does not define any use for a message body." https://datatracker.ietf.org/doc/html/rfc7230#section-3.3

Thus, this feature could prevent users from usage.

[opxdelwin]

As per https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.1-6, it's very unlikely that an API provider would REQUIRE GET method with a body, as they're bound by the same rules.

• 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.

Moreover, GET requests are cached, hence if the response of GET method would dynamically depend upon request content, it'll make no sense for auto-caching GET requests.

[sebastianbuechler]

As per https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.1-6, it's very unlikely that an API provider would REQUIRE GET method with a body, as they're bound by the same rules.

• 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.

Moreover, GET requests are cached, hence if the response of GET method would dynamically depend upon request content, it'll make no sense for auto-caching GET requests.

Maybe you're thinking too narrow. Just imagine a GET endpoint with complex filtering that would exceed the maximum URI length when using query params. Why would you artificially restrict such a usecase?

Also caching would not prevent this usecase nor is it certainly not part of HTTP specs.

I think the main point here is usability though. As HTTP does not restrict the use of a body in GET, people will build endpoints with exactly that. That's also why none of the bigger HTTP clients like postman or insomnia have this feature.

[ashitaprasad]

@sebastianbuechler
@animator has discussed it here #157 & @opxdelwin has already provided the rationale above. We will be following best practice as followed by the industry and not include body with GET.