protoc-gen-openapi: Support oneof generation for messages having only one such field #446
+282
−10
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.
Summary
Related discussion is in #251, with a big disclaimer that this only changes generation for messages with a single
oneof
block. I've gated this behind--openapi_out=oneof=1
to make it opt-in.We sync the generated output to API documentation tooling, and the lack of
oneof
support makes it confusing for consumers to understand how to use endpoints. The techniques in the linked issue don't really address this — they're focused on markingrequired
combinations for the fields. What we need to convey is that the fields can't be provided in the same payload at all.This leaves us with a structure that looks like this:
For a message that has multiple
oneof
, we fallback to normal behavior. Examples of how documentation generators parse this:Redocly
Readme.com
(Using these as a benchmark since they're both popular. One for open source use, the other for enterprise)
Why limited the support?
I started by making each
oneOf
group a descendant ofallOf
to allow for multiple in a message. While this "works", I can't find a documentation tool that supports it nicely. It ends up showing a permutation of eachoneOf
combination. For example:Would generate this:
But it renders terribly on documentation sites:
Redocly
Declaring each
oneOf
with atitle
like{"title": "v1", "oneOf": [...]}
doesn't change anything on eitherredocly
orreadme.com
.Test Plan