-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
[REQ] Support for OpenAPI 3.0-style documented enums #2834
Comments
I did not read carefully the message. openapi: 3.0.1
info:
title: ping test
version: '1.0'
servers:
- url: 'http://localhost:9999/'
paths:
/ping:
get:
operationId: pingGet
responses:
'201':
description: OK
components:
schemas:
SomeObj:
type: object
properties:
someProp:
oneOf:
- enum: [1]
title: Sunny
description: Blue sky
- enum: [2]
title: Cloudy
description: Slightly overcast
- enum: [3]
title: Rainy
description: Take an umbrella with you We could support this, but I am not sure if this is better than |
I understand the point. But if all the major tool implementors follow the same line of thoughts, it will never get supported. Which is not necessarily an issue in itself. However, since it's the recommended way to describe enums by the folks designing JSON-schema and OpenAPI themselves. I believe it would still be great to at least keep it somewhere in the backlog. Since it looks like something relatively easy to implement, maybe keep it tagged with "help wanted"? It wouldn't generate new data structure for the generators, just generate the same as what |
It seems like this would solve the parallel arrays issue for using Regarding the comparison with |
Is your feature request related to a problem? Please describe.
With OpenAPI 3.0 there a pattern that allows to document integer-based enums without having to rely on
x-enum-varnames
andx-enum-descriptions
: OAI/OpenAPI-Specification#681 (comment)Describe the solution you'd like
It would be great to have this pattern supported. Currently, it doesn't generate anything.
Describe alternatives you've considered
We can keep using the old vendor extensions for now. But it would be great to support the new pattern as well.
Additional context
None that I can see.
The text was updated successfully, but these errors were encountered: