Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GET -> POST when user adds request body #178

Open
ashitaprasad opened this issue Feb 24, 2024 · 12 comments
Open

GET -> POST when user adds request body #178

ashitaprasad opened this issue Feb 24, 2024 · 12 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@ashitaprasad
Copy link
Member

ashitaprasad commented Feb 24, 2024

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.

@ashitaprasad ashitaprasad added the enhancement New feature or request label Feb 24, 2024
@opxdelwin
Copy link
Contributor

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

@ashitaprasad
Copy link
Member Author

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

@opxdelwin
Copy link
Contributor

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

@sebastianbuechler
Copy link

@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
Copy link
Contributor

opxdelwin commented Feb 28, 2024

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
Copy link

sebastianbuechler commented Feb 28, 2024

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
Copy link
Member Author

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

@JeetDalal
Copy link
Contributor

JeetDalal commented Aug 9, 2024

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!

Screen.Recording.2024-08-10.at.3.36.24.AM.mov

@JeetDalal
Copy link
Contributor

should there also be a setting to disable this feature as it could be possible that user might not want it?

@ashitaprasad
Copy link
Member Author

ashitaprasad commented Aug 10, 2024

@JeetDalal you can open a PR. We can go through it and discuss more on this feature.

@JeetDalal
Copy link
Contributor

@ashitaprasad I have opened a PR for the issue. Please let me know if any changes are required.

ashitaprasad added a commit to JeetDalal/apidash that referenced this issue Sep 15, 2024
ashitaprasad added a commit that referenced this issue Sep 16, 2024
resolved issue #178(switch from GET->POST if payload exists)
@ashitaprasad
Copy link
Member Author

Current status of this issue is available here -

// TODO: #178 GET->POST Currently switches to POST everytime user edits body even if the user intentionally chooses GET

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants