Skip to content
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

Open
cjllanwarne opened this issue Oct 24, 2024 · 4 comments
Open

Support non-json content types? #39

cjllanwarne opened this issue Oct 24, 2024 · 4 comments

Comments

@cjllanwarne
Copy link

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:

  • An API that returns no content. The only options I seem to have are None which comes back as null and an empty string, which comes back as "".
  • A simple string value. I've refactored a method that used to be equivalent to return web.Response('foo') to be return APIResponse('foo') but over the wire, I'm changing the API behavior. It used to be returning foo but now it returns "foo".

This assumption that all API respond in json requirement seems to be coming from here?

Thank you!

@Dreamsorcerer
Copy link
Member

Dreamsorcerer commented Oct 25, 2024

* An API that returns no content. The only options I seem to have are `None` which comes back as `null` and an empty string, which comes back as `""`.

#21

* A simple string value. I've refactored a method that used to be equivalent to `return web.Response('foo')` to be `return APIResponse('foo')` but over the wire, I'm changing the API behavior. It used to be returning `foo` but now it returns `"foo"`.

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.

@Dreamsorcerer
Copy link
Member

Dreamsorcerer commented Oct 25, 2024

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:

@SCHEMA.api(media_type="text/plain")
def handler(request) -> web.Response:
    ...

@SCHEMA.api()
def handler(request) -> APIResponse[str, Literal[200]]:
    ...

@cjllanwarne
Copy link
Author

I like your suggestion. Are decorators powerful enough to see media_type="text/plain" and know to expect a different response type? Or would we need another decorator like @SCHEMA.text_api or whatever?

Pushing my own use case one more time, would something like @SCHEMA.api_doc(response_shape=...) where we don't validate the types but can use the information to build the openapi schema be possible?

@Dreamsorcerer
Copy link
Member

That might be an option. Will come back to it once the higher priority stuff in done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants