codegen: Support top level nullables on json responses #4351
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
There's probably a couple of ways to represent nullalbility in OpenAPI, neither being "the best". Ideally we would support all of them, so I guess this PR makes sense? It would be most convenient to just focus on 3.1, but that's of course not always possible. |
|
I figure I'll probably try to implement support for optional oneOfs separately from this - as it stands I think it's doing the right thing now for 'nullable' types, but I'd rather we were able to generate the optional for a 'oneOf' with e.g. 200: some content, 204: no content. That's not currently working either, and I find it neater. Edit: that other pr is up. I think it's a stronger usecase, although I guess both might be nice... 🤷 |
|
Let's pull in both since they both add functionality |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Use case for this is being able to migrate an endpoint that returns an 'Option[Foo]'. It seemed to me that adding
nullable: trueis the most natural way to declare this in openapi 3.0; although I'm aware that this was removed in openapi 3.1, so I've also added support for declaring nullability with multiple types (i.e.type: ['null', 'object']). I'm not sure what long-term plans really are for version support, but figured it'd be better to support the feature for both 3.0 and 3.1 specificationsEdit: this might not really be what I want actually. Might want to be able to declare optionality by specifying that one status code (e.g. 204) doesn't return a body, and derive it for a oneOf...