Come funziona il request lifecycle in Spring Boot?

Question

IT Interview Practice · Accepted Answer

In Spring Boot (Spring MVC), una request attraversa il **servlet container**, una catena di **Filter**, il **`DispatcherServlet`** centrale, poi gli **interceptor** e il tuo **`@Controller`**, e il valore di ritorno viene convertito nella risposta HTTP.

## Le fasi

```
Servlet container (Tomcat)
   ▼
Filter chain  ── (CharacterEncoding, Security, CORS, ...)
   ▼
DispatcherServlet  ── il front controller
   ▼
HandlerMapping  ── trova il metodo @Controller
   ▼
HandlerInterceptor.preHandle
   ▼
Argument resolvers  ── binda @RequestBody / @PathVariable / @RequestParam
   ▼
Controller method  ── la tua logica → restituisce object o ResponseEntity
   ▼
HandlerInterceptor.postHandle
   ▼
HttpMessageConverter / ViewResolver  ── serializza in JSON o renderizza la view
   ▼
HandlerInterceptor.afterCompletion → Response ──▶ client
```

1. **Container + filter** — Tomcat consegna la request alla catena di `Filter`. I Filter (inclusa Spring Security) sono il layer più esterno e possono bloccare o avvolgere la request prima che l'MVC la veda.
2. **DispatcherServlet** — il front controller che orchestra tutto ciò che sta sotto.
3. **HandlerMapping** — risolve quale metodo del controller gestisce URL + method.
4. **`preHandle`** — gli `HandlerInterceptor` vengono eseguiti prima del controller (controlli auth, logging, timing); restituire `false` ferma la request.
5. **Risoluzione degli argument** — `@PathVariable`, `@RequestParam` e `@RequestBody` (tramite `HttpMessageConverter`) vengono bindati e validati.
6. **Controller** — il tuo metodo `@RestController` esegue la logica di business e restituisce un object o un `ResponseEntity`.
7. **`postHandle`**, poi il valore di ritorno viene serializzato da un `HttpMessageConverter` (JSON via Jackson) oppure una view viene renderizzata da un `ViewResolver`.
8. **`afterCompletion`** viene eseguito dopo il commit della response; `@ExceptionHandler`/`@ControllerAdvice` gestiscono le eccezioni lungo il percorso.

```java
// 4/7/8. interceptor
public class TimingInterceptor implements HandlerInterceptor {
    public boolean preHandle(HttpServletRequest req, HttpServletResponse res, Object h) {
        req.setAttribute("started", System.nanoTime());
        return true;                       // false = interrompe il flusso
    }
}

// 6. controller
@RestController
class ItemController {
    @GetMapping("/items/{id}")            // 3. mapping
    ResponseEntity<Item> show(@PathVariable Long id) {  // 5. argument resolution
        return ResponseEntity.ok(service.find(id));      // 7. serializzato in JSON
    }
}
```

## Perché è importante

Il lifecycle di Spring ha due layer di estensione distinti che gli intervistatori amano sondare: i **Filter** (a livello servlet, i più esterni — dove vive Spring Security) e gli **Interceptor** (a livello Spring MVC, attorno al controller). Conoscere l'ordine — filter, DispatcherServlet, mapping, interceptor `preHandle`, binding degli argument, controller, conversione dei message, `afterCompletion` — ti dice dove mettere l'autenticazione rispetto al logging, perché un Security filter rifiuta una request prima che giri qualsiasi interceptor o controller, e come `@ControllerAdvice` centralizza la gestione delle eccezioni sull'intero flusso.

Le fasi

Perché è importante

Domande correlate