-
Notifications
You must be signed in to change notification settings - Fork 1
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
Support non-json content types? #39
Comments
I don't have any concrete plans for how non-JSON responses would work in the library just yet (and also not sure how these are represented in OpenAPI yet). First priority will be adding parameter and header support, before I can start thinking about this. But, feel free to provide suggestions on how the API should look for this. |
So, merging thoughts from #40, maybe a valid approach would be to specify the media type in the decorator. When not using the default json type, it should not use/expect an APIResponse as the return type. So, we might have something that looks like:
|
I like your suggestion. Are decorators powerful enough to see Pushing my own use case one more time, would something like |
That might be an option. Will come back to it once the higher priority stuff in done. |
Hello and thanks for a great project!
I wondered whether there's any interest in support for non-json content types?
Two examples I have right now are that I'd like to annotate some existing methods to document:
None
which comes back asnull
and an empty string, which comes back as""
.return web.Response('foo')
to bereturn APIResponse('foo')
but over the wire, I'm changing the API behavior. It used to be returningfoo
but now it returns"foo"
.This assumption that all API respond in json requirement seems to be coming from here?
Thank you!
The text was updated successfully, but these errors were encountered: