Handles whether a request body is set as required or not in the specification. #1608
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As briefly discussed there
The current behavior of the code generation is a mix between always required and always optional bodies.
However the open api specification is pretty clear about that requirement of body
see https://spec.openapis.org/oas/v3.1.0#fixed-fields-10 or https://swagger.io/docs/specification/describing-request-body/
this PR aims to bring the code generation closer to the intent of the open api specification.
using this spec as an example
type declaration
The issue here is that a body is always optional, using a pointer to convey this intent.
current behavior:
a required type will always be a pointer.
suggested behavior:
we drop the ptr since the body was marqued as required in the open api specification.
as seen here, the type generation is considering a request body as being always optional.
strict function handler
The issue here is that a body is always required.
current behavior
suggested behavior:
since the api specification states that the body is not required, which is the default value for the required attribute, we need to check that the body is given to us before trying to decode it.
this may not be a great way to check that the body is there, since a user of the api could set the content type header and not setting a body.
I think this proposed change should be at one point the default behavior of the code generation as it is the default behavior of the open api specification
wdyt ?