foss42
GET -> POST when user adds request body
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.
Hey @ashitaprasad , it is expected to go the other way around, i.e POST -> GET if request body is null?
No, it will not go the other way round, once switched from GET to POST.
@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.
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.
As per https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.1-6, it's very unlikely that an API provider would
REQUIREGET 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.
@sebastianbuechler @animator has discussed it here https://github.com/foss42/apidash/issues/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.
Hello Maintainers,
I am interested in solving this issue and would like to confirm the expected behavior.
-> If the body for any selected content-type is not null, the HTTP method should change only from GET ->POST -> show snackbar only once when changed from GET -> POST -> If the body is null, the method should remain as GET and not revert to POST, correct? Please let me know if this aligns with the expected behavior.
Thank you!
https://github.com/user-attachments/assets/dfea1748-e408-4dfc-afb5-5f551d693e85
should there also be a setting to disable this feature as it could be possible that user might not want it?
@JeetDalal you can open a PR. We can go through it and discuss more on this feature.
@ashitaprasad I have opened a PR for the issue. Please let me know if any changes are required.
Current status of this issue is available here - https://github.com/foss42/apidash/blob/abdd397cb75571d2c7d771ea184d2f5e5b4fde80/lib/screens/home_page/editor_pane/details_card/request_pane/request_body.dart#L20