-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
Issue 721 - Content objects for describing request/response payloads #761
Conversation
@darrelmiller is this solely for the purpose of enabling profiles? Sorry I have been late to the party. Can you reference issues that are solved by this. Thanks. |
As already mentioned in a comment by @fehguy in #721, there is still missing some explanation on how the schema of an As this is also missing for other kinds of parameters, I'm okay with addressing it in a separate PR, I just wanted to mention it here again. I guess #665 will have to address that too. |
@zeeshanejaz The issues addressed by the PR mentioned in the original issue #721. Profiles are simply a way I have found to address the request that some people want to have multiple schemas for the same status code and media type. |
@ePaul Being able to specify multiple response representations opens the door to supporting #146 but I think it is outside of the spec to try and tie a particular input parameter to the selection of the output representation. There is still a server implementation behind the API and it is up to the server to decide which representation will be returned. If the server wants to expose a parameter that directly selects the representation, then it is free to do so. I don't think the OpenAPI spec needs to get involved at this level. |
@ePaul I agree that some discussion of how form-data can be described by schemas is important. But the discussion of how non-JSON data can be described is also bigger than just forms. Hopefully we can address that subject very soon. |
@OAI/tdc let's get your input on this |
"representations" : { | ||
"application/json" : { | ||
"schema": { | ||
"type": "array", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indentation looks weird when rendered via Markdown.
How do representations support the |
"status": | ||
"description" : "Updated status of the pet", | ||
"type": "string" | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like we're going from a flat array of parameters to an object with those fields. Is the intention that we treat the object as an array of form variables?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is my current proposal for mapping form-style key/value pairs into JSON schema.
@whitlockjc I would represent |
updated #761 for naming consistency
# Conflicts: # versions/3.0.md
updated OAI#761 for naming consistency
Issue 721 - Content objects for describing request/response payloads
No description provided.