-
Notifications
You must be signed in to change notification settings - Fork 9.1k
Add 'produces' at response level #660
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
Comments
While this is true, the proposed solution would go too short – we also need to allow responses with the same response code, but differing in |
👍 to what @ePaul wrote - our 200 responses return different representations based on Accept headers; others want different representations based on other (query) parameters, etc. |
How is this different than #146? |
@webron As I understand the original request, this just wants to add a #146 (and my comment) needs e.g. to allow having several 200 responses which differ by its |
Here is my use case to clarify my request. I'm implementing streaming operation using Server-Sent-Events (see #396).
The spec should include enough information to be used to build a client that will send Here is how that would be specified in the produces:
- text/event-stream
- application/json
responses:
'200':
description: Stream is starting
produces: ["text/event-stream"]
default:
# has produces: ["application/json"]
$ref: '#/responses/DefaultError' The The existing spec is only meant to allow the client to choose the MIME type for all responses of an operation just to select the serialisation format between |
In fact, there is already a way to declare responses:
'200':
description: Stream is starting
headers:
'Content-Type':
type: string
enum: ["text/event-stream"] (but unfortunately swagger-ui doesn't (yet) shows the enum) |
With the new Response Object's |
In Swagger 2.0
produces
is defined at theoperation
level and applies to all responses. This forbid to uses different MIME types for different responses and to use for example a specific MIME type for errors, as proposed in RFC 7807 ("Problem Details for HTTP APIs", published in March 2016).The text was updated successfully, but these errors were encountered: