api that consumes text/plain body is still submitted as application/json

[mattoshry]

Edited to better reflect what I'm trying to accomplish...

I'm attempting to define a REST schema using swagger 2.0 where a single path consumes both 'text/plain' and 'application/json' via the request body. While that may not be strictly/elegantly possible based on the thread at [1], I'm curious about the behavior of swagger-ui when I set the consumes array to either ["text/plain"] or ["text/plain", "application/json"].

In the former case, when I 'try it out', the swagger-ui does ultimately set the Content-Type header to "text/plain" but it prints the following to the console:

    server doesn't consume application/json, try ["text/plain"]

In the latter case, swagger-ui insists on setting the Content-Type to "application/json" even though I've selected "text/plain" in the "Parameter content type" drop-down.

Regardless of the current limitation described in [1], rather than resorting/giving in to defining multiple paths to support different request representations, I was hoping that I could fudge the swagger to be 'good enough' until swagger 2.x solves this need. To me 'good enough' means something like:

    "post": {
        "consumes": ["application/json", "text/plain"],
        "produces": ["application/json", "text/plain"],
        "parameters": [
            {
              "name": "body",
              "description": "The input upon which to perform ...",
              "required": true,
              "in": "body",
              "schema": {
                "$ref": "#/definitions/foo"
              }
            },

implying that the JSON representation is described by the referenced schema, but the text representation is simply a string.

Inspecting swagger-client.js (Operation.prototype.setContentTypes), I'm confused by:

if (body && (this.type === 'post' || this.type === 'put' || this.type === 'patch' || this.type === 'delete')) {

In the debugger I see this.type === 'string', and I'm curious as to how this.type should/would ever be set to values that I expect to find associated with this.method.

[1] OAI/OpenAPI-Specification#146

[fehguy]

right you are, this is a bug.

[mattoshry]

Thanks for the quick turnaround on this, Tony.

[bradygaster-zz]

I'm seeing similar behavior when I try to hit Swagger-decorated ASP.NET Web APIs. I'm using Swashbuckle to generate, but I'm using Swagger 1.2 in this project so I'm not using the alpha of Swashbuckle which includes support for 2.0 (just to set context). Interestingly, the API actually gets called properly (and executes fine), but upon the response's return to the client the data isn't handled since this exception is continually thrown by the JS side.

Any idea when this will be included in the NPM package currently available or when a new version will be released?

[fehguy]

I'll be pushing out an updated version tonight

[fehguy]

Actually @bradygaster can you share the swagger spec that you're looking at? The fix here does only apply to swagger-2.0 specs, and it should support posting text/plain if the server reports that it can handle it.

Does your api declare the consumes types?:

{
  "method": "POST",
  "summary": "Add a new pet to the store",
  "notes": "",
  "type": "void",
  "nickname": "addPet",
  "consumes": [
    "application/json",
    "text/plain"
  ]