Skip to content

Endpoints with multiple consuming media types not supported #71

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
akiraly opened this issue Sep 2, 2019 · 6 comments
Closed

Endpoints with multiple consuming media types not supported #71

akiraly opened this issue Sep 2, 2019 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@akiraly
Copy link

akiraly commented Sep 2, 2019

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.

@springdoc springdoc added the enhancement New feature or request label Sep 3, 2019
@springdoc
Copy link
Collaborator

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
Copy link

6sco commented Sep 16, 2019

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.

@springdoc
Copy link
Collaborator

springdoc commented Sep 21, 2019

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
Copy link

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
Copy link
Collaborator

@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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants