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

When API supports multiple content-type, Support for multiple default value is needed #515

Closed
vijayan007 opened this issue Aug 2, 2014 · 3 comments

Comments

@vijayan007
Copy link

  • Assume an api support multiple content types (json & xml)
  • Currently if we set default value for the post body, then automatically option for content-type selection is removed in the current version of the swagger UI
  • This issue to support default value for multiple content types also enable content type selection even if it has a default value
@fehguy
Copy link
Contributor

fehguy commented Aug 2, 2014

We're going to support this in the swagger 2.0 specification

@fehguy fehguy added this to the v2.1.0 milestone Jan 28, 2015
@webron webron added the P3 label May 4, 2015
@fehguy
Copy link
Contributor

fehguy commented May 8, 2015

old issue, but this will be added by 2.1

@webron webron modified the milestones: v2.1, v2.1.1 Jun 8, 2015
@webron
Copy link
Contributor

webron commented Jul 20, 2015

This one is challenging. Let's clarify that the default value is actually intended as the value used by the server when none is provided by the client, the example is intended to provide an actual input example.

The problem is that the ability to describe a structure based on mime type is only available for responses and not requests. For requests, you can only assign examples for definitions which affect body parameters, and even there you can't set it per mime type. This is a limitation of the spec which we'd need to resolve. I've opened a ticket for it so we can follow up on it - OAI/OpenAPI-Specification#418.

We may solve it using vendor extensions for now as workaround.

For now, I'll close the issue as we simply can't deal with it as-is.

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

No branches or pull requests

3 participants