Spring MVC and WebFlux now have built-in method validation support for controller method parameters with @Constraint annotations. That means you no longer need @Validated at the controller class level to enable method validation via AOP proxy. Built-in method validation is layered on top of the existing argument validation for model attribute and request body arguments. The two are more tightly integrated and coordinated, e.g. avoiding cases with double validation. See Upgrading to 6.1 for migration details, and umbrella issue 30645 for all related tasks and feedback.
Method validation is supported with method parameters that are collections, arrays, or maps of objects.
The HandlerMethodValidationException raised by the new built-in method validation exposes a Visitor
API to process validation errors by controller method parameter type, e.g. @RequestParameter, @PathVariable, etc.
MethodValidationInterceptor supports validation of Mono and Flux method parameters, see issue 20781.
Spring MVC raises NoHandlerFoundException by default if there is no matching handler, and ResponseStatusException(NOT_FOUND) if there is no matching static resource, and also handles these with the aim of consistent handling for 404 errors out of the box, including
RFC 7807 responses. See 29491.
ErrorResponse allows customization of ProblemDetail type via MessageSource and use of custom ProblemDetail through its builder.
Spring MVC resets the Servlet response buffer prior to handling error and rendering an error response.
DataBinder now supports constructor binding where argument values are looked up through a NameResolver (e.g. in the HTTP request parameters map), and those lookups can be customized through an @BindParam annotation. This also supports nested object structures through the invocation of constructors necessary to initialize constructor parameters. The feature is integrated in the data binding of Spring MVC and WebFlux and provides a safer option for data binding of expected parameters only, see Model Design for more details. Spring MVC and WebFlux now support data binding via constructors, including nested objects constructors
WebFlux provides option for blocking execution of controller methods with synchronous signature on a different Executor such as the VirtualThreadTaskExecutor, see Blocking Execution in the reference documentation.
SseEmitter now formats data with newlines according to the SSE format.
New RestClient, a synchronous HTTP client that offers an
API similar to WebClient, but sharing infrastructure with the RestTemplate. See 29552.
Jetty-based ClientHttpRequestFactory for use with RestTemplate and RestClient
JDK HttpClient-based ClientHttpRequestFactory for use with RestTemplate and RestClient
Reactor Netty-based ClientHttpRequestFactory for use with RestTemplate and RestClient
Improved buffering in various ClientHttpRequestFactory implementations
HTTP Interface client built-in adapters for the new RestClient and RestTemplate in addition to the existing adapter for the reactive WebClient.
HTTP Interface client supports MultipartFile as an input method parameter.
HTTP Interface client supports UriBuilderFactory as an input method parameter to use instead of the one the underlying is configured with, e.g. if necessary to vary the baseURL dynamically.
The @HttpExchange annotation used on HTTP interface methods is now supported for server side handling in Spring MVC and WebFlux as an alternative to @RequestMapping, see @HttpExchange for more details and guidance.
JVM checkpoint restore support added to Reactor Netty-based ClientHttpRequestFactory for use with RestTemplate and RestClient and ClientHttpConnector for use with WebClient; see 31280, 31281 and 31180.
General Coroutines support revision in WebFlux, which includes CoroutineContext propagation in CoWebFilter, CoroutineContext propagation in coRouter DSL with filter, a new context function in coRouter DSL, Support for @ModelAttribute with suspending function in WebFlux and consistent usage of the Mono variant of awaitSingle().
Support Kotlin parameter default and optional values in HTTP handler methods; see 21139 and 29820.