Response Messages's Response Model not shown

[sosoxuc]

Response Messages's Response Model not shown in case if primitive types e.g for string

[fehguy]

more info, please :)

[sosoxuc]

Have tried both

"responses": {
                    "200": {
                        "description": "Result of operation.",
                        "type": "string"
                    }
                }

"responses": {
                    "200": {
                        "description": "Result of operation.",
                        "schema": {
                            "type": "string"
                        }
                    }
                }

[webron]

FYI, only the second option is valid:

"responses": {
                    "200": {
                        "description": "Result of operation.",
                        "schema": {
                            "type": "string"
                        }
                    }
                }

[sosoxuc]

But nothing is shown in marked area :(

[webron]

I didn't say it solves the issue, just wanted you to be aware the first option is a malformed Swagger spec.

[sosoxuc]

Thanks

[lucianomedina]

Hello, I have the same problem. Someone could solve it?

[webron]

Let's make sure it's the same issue. Can you share your own responses definition?

[lucianomedina]

"responses": {
    "500": {
        "description": "Unexpected error",
        "schema": {"$ref": "#/definitions/500"}
    }
}

"definitions": {
    "500": {
        "schema": {
            "type": "array",
            "items": {
                "50002": {
                    "code": 50002,
                    "message": "error ex"
                },
                "50003": {
                    "code": 50003,
                    "message": "error ex 2"
                }
            }
        }
    }
},

The swagger version is 2.0.24.
Thanks!

[webron]

That's not a valid definition. "items" cannot contain multiple entries.

Also, the definitions should have been something along the lines of:

"definitions": {
    "500": {
        "type": "array",
        "items": { ... }
    }
},

[avishaan]

I'm having the same problem as @sosoxuc

        "responses": {
          "200": {
            "description": "A-Ok",
            "schema": {
              "type": "string"
            }
          }
        }

It may look like the screenshot cut it off but I assure you it isn't there.

[gregzuro]

I am also, I think, seeing this issue.

The models that are array[...] do not appear while the non-array one does.

This json was 'auto-created' by go-restful, FWIW.

https://gist.github.com/gregzuro/519e97958d386b2f50c4

[fehguy]

OK I've confirmed the case I was aware of is fixed in develop_2.0. Please reopen if you see issues after you test with 2.1.0-M1

[j3kz]

I'm seeing this issue in 2.1.8-M1

[ponelat]

I've been investigating the issue, and there is a "fork in the road", when it comes to the fix.

We're dealing with the operation's responses:
For starters, we pick out a success response (2XX) and promote it to the top of the UI's operation view.
Then we leave the rest of the responses pretty much untouched from the spec, as plain objects.

This means when we want a "rendered" JSON and Model view, when need to build it from the response object.
For response objects with a schema->$ref, we deference them from the list of model definitions.
Sounds about right... but its done from inside the -UI.

To solve the above, we must either add more logic to the -UI regarding response objects. Such as "create an inline model instance" and "determine if its an object or primitive"

The other alternative, is to process the response objects inside -JS, creating model instances where we need to. I don't know if anything(anyone) else depends on response objects schema's being plain objects. And whether they would be affected by this little refactor.

In the end, it'll take maybe two hours to patch the code to work as everyone expects, but do we want to patch this or refactor it and simplify?

@fehguy, @whitlockjc, @mohsen1 - thoughts?

[rutchkiwi]

got the same problem over here!

[dariusz]

Hey @ponelat -- not sure if it helps your decision to generate within -ui or -js, ... but honestly, even something as simple as listing the name of the ResponseModel (without rendering it) would be a great first step.

[fehguy]

There is a meta-issue to support schemas differently and not render in the swagger-js client. I'm going to add tasks to that meta issue, reference this and other related issues, and close this out.