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

Allow documenting alternative response content-type #77

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

alechoey
Copy link

I'm interested in using quart-schema as a drop-in replacement for apiflask to generate OpenAPI documentation for my application.

So far, I've been able to use validate_response to generate relevant documentation for all of my application/json endpoints.

When it comes to my other content-types, such as text/event-stream, I've been able to successfully document the headers with Pydantic models with the signature:

from pydantic import BaseModel, Field, ConfigDict, RootModel

def to_kebab(field_name: str) -> str:
    return field_name.replace("_", "-")


class StreamHeaders(BaseModel):
    model_config = ConfigDict(alias_generator=to_kebab)
    content_type: Literal["text/event-stream"] = Field(default="text/event-stream")


class StreamResponse(RootModel):
    root: bytes


@app.route("/")
@validate_response(StreamResponse, 200, StreamHeaders)
def index():
    async def async_generator():
        yield "hello"
        yield "world"
    return async_generator(), 200, StreamHeaders().model_dump(by_alias=True)

However, this yields me the following OpenAPI docs:

/:
  get:
    operationId: get_index
    parameters: []
    ...
    responses:
      '200':
        content:
          application/json:
            schema:
              format: binary
              title: StreamResponse
              type: string
          headers:
            content-type:
              schema:
                const: text/event-stream
                default: text/event-stream
                title: Content-Type
        description: ''
      ...

Instead of documenting the response as application/json, I would like it to use the relevant literal from the Headers class that I've provided. I've added a simple test case to demonstrate.

@pgjones
Copy link
Owner

pgjones commented May 15, 2024

I'm going to give this more consideration. I think Quart-Schema might benefit from a way to consider alternative/multiple content-types in a general sense.

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

Successfully merging this pull request may close these issues.

2 participants