How can multiple response content types and parameter content type be set?

[pietervogelaar]

At the moment only application/json is available. What is required to add application/xml as option to the selectbox?

[hsanjuan]

Im also interested

[hsanjuan]

So, I checked and you would need to add something like "supportedContentTypes : ['application/json', 'text/yaml']" in each of the "operations" objects. This will populate the select and set the Accept header when clicking "try out". It is not documented afaik, maybe wasnt in latest stable release. Cheers

[fehguy]

Hi folks, you can use that current field, but for the next release, supportedContentTypes will be changed to follow the updated spec, which should have more clear naming, and inheretence and overrides at the method level. The supportedContentTypes is well written, but it will be renamed for the 1.2 spec, which hopefully will be wrapped up this month.

[caoilte]

Hi,
Did the 1.2 spec ever get released? I'm also interested in supporting xml and json. The only thing I could find was this,

https://github.com/wordnik/swagger-core/wiki/changelog

which suggests not.

[fehguy]

No, it hasn't. The sticking point has been JSON schema (swagger-api/swagger-core#51), which many folks have asked for but seems insufficient for doing what swagger needs to. So until that gets resolved either way, the spec hasn't been released.

[caoilte]

Ok,
I've added support for the supportedContentTypes field in my fork of Scalatra, caoilte/scalatra@c70f002. Do you think it would be worth my while trying to get it merged into master?

[fehguy]

Yes, I know @casualjim is looking at this as well so that'd be helpful for sure. Clarification though, 1.2 spec uses the names "produces" and "consumes". Sorry that wasn't clear

[cadenzajon]

I have had this working fine for months, with Swagger out of the box. My JSON looks like:

{
"swaggerVersion": "1.1",
"resourcePath": "/document_list",
"apis": [
{
"path": "/document_list",
"operations": [
{
"httpMethod": "GET",
"summary": "Search for documents based on a set of criteria",
"produces": [
"application/json",
"application/xml",
"application/atom+xml"
],
...

The most annoying thing is that two "Response Content Type" dropdowns appear in swagger-ui, one at the top of the operation (above the parameters) and one embedded within my Message Body parameter area (which is redundant and seems to be completely ignored).

For API calls with no Message Body parameter (i.e. a GET as opposed to PUT, POST) the UI works great and I have no complaints.

Is there any possibility that the "Response Content Type" dropdown could be suppressed within the Message Body parameter when it exists at the top level of the operation?

[AndrewCsontos]

There is a difference between the two. The top level one sets an "Accept" header. The parameter level one sets the "content-type" header.

So you could in theory post Json and ask for Xml back.

[cadenzajon]

Ah, of course. Is there a way to add items to that embedded "content-type"
list? I have had to add my own "Content-Type" parameter when I want to)
provide alternate options to JSON (like "application/xml").

On Tue, Jun 11, 2013 at 12:28 PM, AndrewCsontos [email protected]:

There is a difference between the two. The top level one sets an "Accept"
header. The parameter level one sets the "content-type" header.

So you could in theory post Json and ask for Xml back.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/119#issuecomment-19286396
.

[fehguy]

This is added to 2.0-develop. Please try it out and post back if you see issues.

[akhil]

@fehguy produces works, but consumes doesnot when defaultValue is set.

[webron]

@akhil - defaultValue of what?

[akhil]

I used http://demo0536639.mockable.io/api-docs at http://petstore.swagger.wordnik.com/
In the http://demo0536639.mockable.io/api-docs/assets there is "defaultValue": "{}", in 'parameters'
The textbox gets populated by {} as expected. But the dropdown is missing.

When I remove the defaultValue entry I see the dropdown

[webron]

@akhil - okay, this is an interesting issue, but it's somewhat different than the topic at hand. Can you open a separate issue with the details you gave here?

[akhil]

done #593