Endpoints with multiple consuming media types not supported

[akiraly]

I have a webflux controller like this:

@RestController
@RequestMapping("/foo")
public class FooController {

  @PostMapping(path = "/bar/baz", consumes = "application/x.a+json", produces = MediaType.TEXT_PLAIN_VALUE)
  public String process1(@RequestBody A a) {
    return a.toString();
  }

  @PostMapping(path = "/bar/baz", consumes = "application/x.b+json", produces = MediaType.TEXT_PLAIN_VALUE)
  public String process2(@RequestBody B b) {
    return b.toString();
  }
}

Note that both java methods are bound to the same path - /foo/bar/baz and same HTTP method - POST. The only difference is in the consumed media type.

Spring Boot 2.1.7 supports this and can call the appropriate method based on the content type sent by the client.

However in case of springdoc only one of the methods are exposed. I think the Swagger UI would support multiple different media types because it has a drop down for it but currently it only has one element instead of 2.

This feature is not a priority and the importance should be proven before being addressed.
It's not the natural choice, to create two methods for the same API resource. I will encourage you to refactor and review the design of the APIs instead.

For example, if you have swagger annotation @operation with a description of both, which one will be chosen?
The same question for all the fields. summary, operationId.

You will need to clearly define the expected OpenAPI Description as well, using the swagger annotations on both methods.

[6sco]

Hi, same problem for me.

According to OAS 3 specification: it is possible to define multiple content for one path with one method. Witch provide a combo box in swagger ui to let the user choose the content-type.

paths:
      /pets:
        post:
          summary: Add a new pet
          requestBody:
            content:
              application/json:
                schema:
                  $ref: '#/components/schemas/Pet'
              text/plain:
                schema:
                  type: string
          responses:
            '201':
              description: Created

That description as to be implement like this with Spring:

@PostMapping(value = "/pets", consumes =  "application/json")
public ResponseEntity<Void> petsPost(@Valid @RequestBody Pet pet) {
        return new ResponseEntity<Void>(HttpStatus.NOT_IMPLEMENTED);
}
@PostMapping(value = "/pets", consumes = "text/plain")
public ResponseEntity<Void> petsPost(@Valid @RequestBody String pet) {
        return new ResponseEntity<Void>(HttpStatus.NOT_IMPLEMENTED);
}

The same issue 2159 is open on Springfox.

Hi,

This enhancement will be available on v1.1.41.
One overloaded method on the same class, with the same HTTP Method and path, will have as a result, only one OpenAPI Operation generated.

In addition, it's recommended to have the @operation in the level of one of the overloaded methods. Otherwise it might be overriden if its declared many times within the same overloaded method.

[birnbuazn]

It's not the natural choice, to create two methods for the same API resource. I will encourage you to refactor and review the design of the APIs instead.

I couldn't disagree more. This is the natural choice, if for instance you want to support two different versions of the API and differentiate between versions based on the media type. Which is again the recommended way of doing things.

[bnasslahsen]

@birnbuazn,

First of all, there are many versioning strategies of Rest APIs, and using the Accept Header is just one of them. And each one has advantages and disadvantages.

Secondly, the example provided doesn't reference two different Accept Headers, because the different produces that are provided are the same.

So i am not sure how much your comment is relevant, because this enhancement has been added and supported for a while .

[ndtreviv]

I have an endpoint where content can be submitted either as multipart/form-data or as raw JSON in the request body.

The same endpoint, overloaded with two different Accept headers.