Spring MVC request lifecycle

Spring MVC uses the Servlet model. It is a strong default for most blocking web applications.

Request path

1. The servlet container accepts HTTP.
2. Filters run, including the Spring Security filter chain.
3. DispatcherServlet receives the request.
4. A handler mapping finds a controller method.
5. An adapter resolves arguments and invokes the method.
6. The controller calls application services.
7. Return-value handlers and message converters create the response.
8. Exception handlers translate failures.

Controller boundaries

Controllers translate HTTP into application commands and results. Keep business rules in application/domain services. Validate input at the boundary with Bean Validation and use explicit request/response DTOs instead of exposing entities.

MVC or WebFlux?

Choose MVC for blocking libraries and the ordinary thread-per-request model. Choose WebFlux when the whole important path is non-blocking and the workload benefits from many concurrent waiting operations or streaming. Wrapping JDBC in a reactive controller does not make it non-blocking.

REST clients

Modern Spring offers RestClient for synchronous use and WebClient for reactive use. Configure timeouts, connection pools, observability, error mapping, retries, and authentication. Do not create a new client per request.

Feynman check

DispatcherServlet is the reception desk. It finds the right controller, converts the envelope into Java data, and converts the answer back into HTTP.