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 multiple content-type responses #583

Open
toteto opened this issue Apr 15, 2024 · 0 comments
Open

Support multiple content-type responses #583

toteto opened this issue Apr 15, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@toteto
Copy link
Contributor

toteto commented Apr 15, 2024

Is your feature request related to a problem? Please describe.

There are cases where the having more flexible content-type response header value makes sense. Some come from the content type the client requests/supports, other is where the server picks what is best content-type depending on the logic.

Describe the solution you'd like

Initially I think that c.otherResponse should be considered as place to implement this feature in the contract. One option is to have the contentType be an array with all options instead of string, where the body would be union of the schemas. But more appropriate would be I think to have union of the whole response.

Something like this:

responses: {
    200: c.otherResponse([
        { contentType: 'application/json-ld', body: c.type<void>() }, 
        { contentType: 'application/json', body: c.type<void>() }
    ]),
},

On the server side, probably returning content-type under headers would be sufficient?

Describe alternatives you've considered

The current workaround is to have separate response entries and disregard the HTTS status code:

responses: {
    200: c.otherResponse({ contentType: 'application/json-ld', body: c.type<void>() }),
    201: c.otherResponse({ contentType: 'application/json', body: c.type<void>() }),
},
@toteto toteto added the enhancement New feature or request label Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant