-
-
Notifications
You must be signed in to change notification settings - Fork 526
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
Comments
This feature is not a priority and the importance should be proven before being addressed. For example, if you have swagger annotation @operation with a description of both, which one will be chosen? You will need to clearly define the expected OpenAPI Description as well, using the swagger annotations on both methods. |
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. 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. |
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. |
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 . |
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. |
I have a webflux controller like this:
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.
The text was updated successfully, but these errors were encountered: