Swagger-ui: examples for status code other than 200 do not display

Created on 18 Feb 2016 · 40Comments · Source: swagger-api/swagger-ui

Examples for 200 status codes show just fine.

Any custom examples added to specific error response codes in the YAML spec do not show, default examples are shown instead.

Source

alexmnyc

👍15

Most helpful comment

Hello. i am using swagger ui 3.0.10 and still have this issue. Can someone double-check it?

igorko on 22 May 2017

👍5

All 40 comments

Can you share a sample spec for us to test?

webron on 18 Feb 2016

responses:
        200:
          description: returns success response
          schema:
            $ref: '#/definitions/SomeSuccessResponse'
          examples:
            application/json: |-
              {
                "header": {
                  "request": "/v1/someid"
                },
                "body": {                  
                  "dai_method": "some"
                }
              }
        401:
          description: No Token Provided
          schema:
            $ref: '#/definitions/ErrorResponse'
          examples:
            application/json: |-
              {
                "header": { 
                  "request": "/v1/someid"                
                  "errors": [
                    "No Token Provided"
                  ],
                  "status": "ERROR"
                }
              }

alexmnyc on 18 Feb 2016

Same problem here.

I uploaded an example that you can test: https://gist.githubusercontent.com/jmmercadom/18f5b8380b741c22689f/raw/f828c3bc76191c077e1ade7df0393e8701fdb891/swagger_response_examples.json.

Using the online demo http://petstore.swagger.io you can notice that the example provided for the 400 and 500 HTTP code are not showed but the one for the 200 HTTP code it is showed.

But if you use Swagger editor http://editor.swagger.io you and upload the same example you can see that the example for the three HTTP codes (200, 400 and 500) are showed.

I think that the first one uses SwaggerUI and the second is using other ways (AngularJS) to visualize the specification. This make me think that probably is an issue with SwaggerUI.

I hope that with this information is more clear what is the problem.

jmmercadom on 24 Feb 2016

ghost on 25 Feb 2016

firefoxNX on 9 Mar 2016

+1, is there anything you can do about this? It's a blocker for us. Seems related to #618

andrzejwp on 23 Mar 2016

Georgevik on 22 May 2016

mikefeldmangh on 24 Jun 2016

kneket on 5 Jul 2016

killmag10 on 7 Jul 2016

hallconama on 15 Jul 2016

+1. I'll see if I can sort a PR

dupski on 20 Jul 2016

Blagomir on 24 Aug 2016

JodyLognoul on 7 Sep 2016

jfach on 22 Sep 2016

IvanVas on 19 Oct 2016

bkapellusch on 19 Oct 2016

IsmetKh on 24 Oct 2016

aleixverges on 30 Nov 2016

anestik on 30 Nov 2016

cbandav on 5 Dec 2016

Jwagner347 on 6 Dec 2016

@webron is it possible to get this addressed?

jfach on 8 Dec 2016

@Jfach - we're very focused right now on a major update, and unfortunately don't have the capacity to address this right now. If someone can whip up a PR to support it, I'll do my best to push it to be reviewed and merged.

webron on 8 Dec 2016

👍1

mmaio on 19 Dec 2016

Saucistophe on 28 Dec 2016

Fadelis on 13 Jan 2017

@webron no worries. Thank you!

jfach on 20 Jan 2017

Hi guys,

Being looking at the issue but I haven't manage to figure it out just yet. Let me write my findings so far, will keep trying this week:

Looking at the OperationView.js file there is the following code:

if (typeof this.model.responses !== 'undefined') {
      this.model.responseMessages = [];
      ref2 = this.model.responses;
      for (code in ref2) {
        value = ref2[code];
        schema = null;
        schemaObj = this.model.responses[code].schema;
        if (schemaObj && schemaObj.$ref) {
          schema = schemaObj.$ref;
          if (schema.indexOf('#/definitions/') !== -1) {
            schema = schema.replace(/^.*#\/definitions\//, '');
          }
        }
        isJSON = value.examples;

        this.model.responseMessages.push({
          code: code,
          message: value.description,
          responseModel: schema,
          headers: value.headers,
          schema: schemaObj,
        });
      }
    }

As yo ucan see there is no reference at all to the sample code provided to the response. The funny part is that a few lines later there is specific code only for an attribute of the model called successResponse in which it does actually take it into account:

if (this.model.successResponse) {
      successResponse = this.model.successResponse;
      for (key in successResponse) {
        value = successResponse[key];
        this.model.successCode = key;
        if (typeof value === 'object' && typeof value.createJSONSample === 'function') {
          this.model.successDescription = value.description;
          this.model.headers = this.parseResponseHeaders(value.headers);
          signatureModel = {
            sampleJSON: isJSON ? JSON.stringify(SwaggerUi.partials.signature.createJSONSample(value), void 0, 2) : false,
            isParam: false,
            sampleXML: isXML ? SwaggerUi.partials.signature.createXMLSample(value.name, value.definition, value.models) : false,
            signature: SwaggerUi.partials.signature.getModelSignature(value.name, value.definition, value.models, value.modelPropertyMacro)
          };
        } else {
          signatureModel = {
            signature: SwaggerUi.partials.signature.getPrimitiveSignature(value)
          };
        }
      }
    }

I thought 🤔 , hey maybe if I pass the sampleJSON property to the responseMessages object might work. The problem comes then that for some weird reason the successsResponse has a ton of attributes that the other responses do not have and one that it is necessary seems to be the 'definition' one.

(There is no value on doing this, just wanted to give it a shot) And to make it even more complicated, you can try to create a path with a get response which will respond with the 200 error message and the example data that you want.

get:
  tags:
  - Error
  summary: Just an error
  description: "Just an error"
  operationId: errorGet
  responses:
    200:
      description: "Bad request"
      schema:
        $ref: '#/definitions/Error'
      examples:
        application/json:
          {
            "code": "40014",
            "key": "email_already_exists",
            "message": "Email already exists",
          }

THEN that exact same data will populate the example in the UI for the other endpoints which in their error response are using the Error definition, taking into account that for some really weird reason, will not take into account the example response you put in the 400 error response but will ALWAYS take the one you define in the 200 error response endpoint (which should not be there in the first place anyway).

Well lot of words but I help that maybe someone can point towards the direction where to fix it or even chip in and solve it together ;)

javier-tarazaga on 25 Jan 2017

👍1

ekoome on 6 Feb 2017

brummetj on 14 Feb 2017

strpipe on 14 Feb 2017

jruehlin on 18 Feb 2017

It might not be the exact problem, but I've traced the issue back to swagger-client.js

in https://github.com/swagger-api/swagger-js
in types/operation.js:

if (responses['200']) {
    response = responses['200'];
    defaultResponseCode = '200';
  } else if (responses['201']) {
    response = responses['201'];
    defaultResponseCode = '201';
  } else if (responses['202']) {
    response = responses['202'];
    defaultResponseCode = '202';
  } else if (responses['203']) {
    response = responses['203'];
    defaultResponseCode = '203';
  } else if (responses['204']) {
    response = responses['204'];
    defaultResponseCode = '204';
  } else if (responses['205']) {
    response = responses['205'];
    defaultResponseCode = '205';
  } else if (responses['206']) {
    response = responses['206'];
    defaultResponseCode = '206';
  } else if (responses['default']) {
    response = responses['default'];
    defaultResponseCode = 'default';
  }
  //[...] (code non essential for the logic)
  if (response && response.schema) {
    var resolvedModel = this.resolveModel(response.schema, definitions);
    var successResponse;

    delete responses[defaultResponseCode]; // <-- Commenting out that line adds back the 2XX responses
    [...]
 }

It looks like it's finding the 1st success code, putting it on the side to be displayed in the main panel, and removing it from the list of responses.

To be honest it probably should be in both places as it's part of the responses. Especially since you can have more than 1 success code depending on what the api is doing. Like 201 and 207 isn't so uncommon.

Tests are failing when I remove it, because it's adding 200 as a default for a test case.

This might help someone fix it properly...

MiiRaGe on 24 Feb 2017

Should no longer be an issue with 3.X. Please reopen otherwise.

webron on 24 Mar 2017

🎉1

Hello. i am using swagger ui 3.0.10 and still have this issue. Can someone double-check it?

igorko on 22 May 2017

👍5

@igorko please file a new ticket.

webron on 24 May 2017

+1
still same issue??

RahmanM on 22 Jul 2018

WOW. NO EXAMPLES OTHER THAN 200 SHOW UP? We have like 500 APIs with numerous examples for many status codes. This is such an epic failure, that we're going to have to drop swagger altogether if this isn't fixed. WOW. It's like... "swagger shows examples" (then in the fine print "but 99/100 won't display, because of a bug from 2016 that still hasn't been addressed). WOW. This has been getting +1's for one month shy of 3 years now. Come on.