Support extracting Bean Validation constraints from method parameters

[JunggiKim]

First of all, thank you for maintaining Spring REST Docs. I really appreciate the project and your time.

Problem

Spring REST Docs' Bean Validation constraint support is currently property-centric.

• ConstraintDescriptions.descriptionsForProperty(String)
• ConstraintResolver.resolveForProperty(String, Class<?>)

In real controllers, validation is often declared on method parameters (@RequestParam, @PathVariable, etc.), but there is no standard API path to extract/document those constraints.

Example

@Validated
class KeywordController {

    @GetMapping("/keywords/{id}")
    void getPopularKeywords(
        @RequestParam @Min(1) int limit,
        @PathVariable @Pattern(regexp = "^[A-Z0-9_-]+$") String id
    ) {
    }
}

Why this matters

Without a standard extraction path for method parameters, generated parameter docs can diverge from runtime validation rules for query/path/form parameters.

Suggested direction

A dedicated API entry point for method-parameter constraints, for example:

• a new helper class (e.g., MethodParameterConstraintDescriptions), or
• an explicit overload that accepts method/parameter metadata.

The intention is to keep resolution explicit and deterministic, aligned with Spring REST Docs' existing philosophy.

I understand that custom ConstraintResolver is already supported, but the current standard entry point is still property-based (property, Class<?>).

Related context

• Existing nested-path issue: Provide support for more sophisticated path-based constraint description resolution #106
• Related constraint issues: Add support for resolving Bean Validation's container element constraints #717, Add support for Bean Validation's constraint groups #887
• Current constraints reference docs: https://docs.spring.io/spring-restdocs/reference/documenting-your-api/constraints.html

Acceptance criteria

• Supports common Bean Validation annotations on method parameters (@Min, @Max, @Pattern, @NotBlank, etc.)
• Works for @RequestParam and @PathVariable use cases
• Keeps backward compatibility with existing property-based APIs
• Clearly documented usage in reference docs

If this direction is acceptable, I would be happy to prepare a PR.

Thank you again for your work on Spring REST Docs.

[wilkinsona]

Thanks for raising this, @JunggiKim. This sounds generally useful and a PR would be welcome.

I think the hardest part will perhaps be identifying the method from which the constraints should be extracted in a concise way. I can envisage something like resolveForArgument(String argument, String method, Class<?> clazz) but that won't work for overloaded methods. Perhaps that can be offered for methods where there's no overload and a more complex resolveForArgument(String argument, String method, Class<?>[] parameterTypes, Class<?> clazz) can be offered for the overload case.

[JunggiKim]

Hi @wilkinsona, thank you for the feedback and the suggested API direction.

I've opened PR #1035 that adds support for method parameter constraint extraction.

Regarding the API shape — I considered the resolveForArgument(String argument, String method, Class<?>) approach you mentioned, but ended up going with resolveForMethodParameter(Method, int) instead. The main reason is that using Method + parameter index avoids the overload ambiguity problem entirely, without needing a separate Class<?>[] overload. It also stays close to how Bean Validation's own ExecutableDescriptor works internally.

That said, I'm very open to adjusting the API design if you'd prefer a different direction. Happy to iterate on the PR based on your feedback.