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

Should we support the requestBody? #182

Open
ms14981 opened this issue Mar 16, 2023 · 2 comments
Open

Should we support the requestBody? #182

ms14981 opened this issue Mar 16, 2023 · 2 comments
Labels
question Further information is requested

Comments

@ms14981
Copy link
Contributor

ms14981 commented Mar 16, 2023

In our requestBody.feature, we specifically assert that a GET request should accept a body. However, the OpenApi spec says:

In other cases where the HTTP spec is vague (such as GET, HEAD and DELETE), requestBody is permitted but does not have well-defined semantics and SHOULD be avoided if possible.

See https://swagger.io/specification/#operation-object

Perhaps we shouldn't have this test, or if we don't test the same thing elsewhere, repurpose it to make it into a POST (or other method with a well-defined spec for the request body)?

@ms14981
Copy link
Contributor Author

ms14981 commented Mar 24, 2023

TODO - see how straightforward this is to support anyway in the Java generator. If it's not difficult, support it anyway. If it is, it's fine for the Java generator to fail this test.

@ColinEberhardt ColinEberhardt added the question Further information is requested label Mar 29, 2023
@ColinEberhardt ColinEberhardt changed the title Updates to requestbody.feature Should we support the requestBody? Mar 29, 2023
@ColinEberhardt
Copy link
Collaborator

We discussed this recently. The conclusion was:

  • while the use of request bodies is somewhat undefined for various HTTP verbs, we should still support it
  • for languages / frameworks where it is difficult to do so (e.g. the HTTP library does not permit request bodies for GET requests), we should not support
  • this means that we expect some generators to fail this test - which is fine. It is an indication that they do not support a certain capability which is not at all critical

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants