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.