-
-
Notifications
You must be signed in to change notification settings - Fork 467
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
Support @Validated validation groups #510
Comments
You can achieve your expected OpenAPI description, by using |
Can you provide an example on how to achieve this using |
Always the worst to stumble on a thread that is asking for exactly what you need and the last comment is a question that's a year old 😞. @omarAbdelhadyok did you solve your use case? |
@bensaufley A method like this might help: @RestController
@RequestMapping("controller")
public class Controller {
@PutMapping
public void put(
@RequestBody
@io.swagger.v3.oas.annotations.parameters.RequestBody(
content = @Content(
schema = @Schema(
// See https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Annotations#schema
implementation = Request.class,
requiredProperties = {"name"}
)
)
)
@Validated(Request.PUT.class) Request request
) {}
@PatchMapping
public void patch(
@RequestBody
@io.swagger.v3.oas.annotations.parameters.RequestBody(
content = @Content(
schema = @Schema(
// See https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Annotations#schema
implementation = Request.class,
requiredProperties = {}
)
)
)
@Validated(Request.PATCH.class) Request request
) {}
} As with the original issue, this is still not DRY.. |
plan support it? |
Is your feature request related to a problem? Please describe.
Using one request object for PUT and PATCH methods and using @Validated annotation with validation groups should respect the validation of the group.
Generates: irrelevant parts omitted for brevity
Describe the solution you'd like
In the above example the patch route should have name as an optional parameter, not required
Something like:
Describe alternatives you've considered
Obvious alternative is different request objects. Though this is annoyingly verbose for the above case.
The text was updated successfully, but these errors were encountered: