-
Notifications
You must be signed in to change notification settings - Fork 155
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
Fixing response documentation for OpenAPI 3.x #153
base: master
Are you sure you want to change the base?
Conversation
1d5b402
to
60779ef
Compare
Hi It would be really great if you'll find time to review given MR. As @rusnyder perfectly described there are some differences in Swagger 2.0 & OpenAPI Schema 3.0 response definition and currently, with Thanks in advance! Hi @rusnyder, I understand, that you might be off topic already, but what do you think about allowing configuring default content type for the app instead of using default content_type = meta['content_type'] or 'application/json' Something like |
How come this hasn't been merged yet? |
Bump. It would appear the maintainer has left the building. |
Please merge this 😅 |
meta.pop('content_type', None) | ||
exploded[status_code] = meta | ||
else: | ||
content_type = meta['content_type'] or 'application/json' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rusnyder I think it would be better if you use the get method to get the data so that it won't get errors when content_type
does not exist in the meta
. Something like this:
content_type = meta.get('content_type') or 'application/json'
Currently, the
responses
OpenAPI docs are generated in OpenAPI 2.0 format regardless of specified version. This just updated theresponses
formatting to handle OpenAPI 3.0 appropriately.OpenAPI 2.0:
OpenAPI 3.0: