springmvc: @ResponseStatus annotation for CREATED results in doubled response description

Generated result:

...
"responses" : {
  "200" : {
    "description" : "successful operation",
      "schema" : {
      "$ref" : "#/definitions/ResultDto"
    }
  },
  "201" : {
    "description" : ""
  }
}
...

Expected result:

...
"responses" : {
  "201" : {
    "description" : "successful operation",
      "schema" : {
      "$ref" : "#/definitions/ResultDto"
    }
  }
}
...

[a-n710]

    @ResponseStatus(code = HttpStatus.ACCEPTED)
    public ResponseEntity<String> test1()
...
    @ResponseStatus(code = HttpStatus.ACCEPTED)
    public String test2()

from my perspective both of these methods should result in

        202:
          description: "successful operation"
          schema:
            type: "string"

At the same time, both of these

    @ApiResponses({@ApiResponse(code = 201, message = "201 message"), @ApiResponse(code = 409, message = "conflict message")})
    public String test4()
...
    @ResponseStatus(code = HttpStatus.CREATED)
    @ApiResponses({@ApiResponse(code = 201, message = "201 message"), @ApiResponse(code = 409, message = "conflict message")})
    public String test5()

should result in

        201:
          description: "201 message"
          schema:
            type: "string"
        409:
          description: "conflict message"

and finally,

    @ResponseStatus(code = HttpStatus.OK)
    @ApiResponses({@ApiResponse(code = 201, message = "201 message"), @ApiResponse(code = 409, message = "conflict message")})
    public String test6()

should also be converted into

        201:
          description: "201 message"
          schema:
            type: "string"
        409:
          description: "conflict message"

The last one is a little controversial and can be expected to become

        200:
          description: "successful operation"
          schema:
            type: "string"
        201:
          description: "201 message"
        409:
          description: "conflict message"

but I think that if someone is explicitly specifying api responses there is no reason to avoid defining all of them, including the 200 one, if needed. Currently you PR fails to specify type: string in all cases and duplicates status code in the test1-test2 block .

[bratwurzt]

As far as I can see, if we merge our PRs, result should satisfy both parties: if ApiResponses is specified, we ignore ResponseStatus and assume that definition in ApiResponses is complete.

I don’t think so - the whole point of this PR is to remove/replace default 200 response (which is added in com.github.kongchen.swagger.docgen.reader.SpringMvcApiReader#parseMethod) in special cases where you don’t want 200 at all. For example - combination of ResponseStatus(201) and ApiResponse(204) is perfectly legitimate: 201 is default, 204 is a special case. I don’t think we should override scheme or description in case of 204 with the one from 200 - no content has no content. Also the case which you pointed out at the end - if you set any ApiResponses and have set default on ResponseStatus, it will be ignored.