Comment fonctionne le cycle de vie d'une requête dans Spring Boot ?

Question

IT Interview Practice · Accepted Answer

Dans Spring Boot (Spring MVC), une requête traverse le **servlet container**, une chaîne de **Filters**, le **`DispatcherServlet`** central, puis les **interceptors** et votre **`@Controller`**, et la valeur de retour est convertie en HTTP response.

## Les étapes

```
Servlet container (Tomcat)
   ▼
Filter chain  ── (CharacterEncoding, Security, CORS, ...)
   ▼
DispatcherServlet  ── le front controller
   ▼
HandlerMapping  ── trouve la méthode @Controller
   ▼
HandlerInterceptor.preHandle
   ▼
Argument resolvers  ── bind @RequestBody / @PathVariable / @RequestParam
   ▼
Controller method  ── votre logique → retourne object ou ResponseEntity
   ▼
HandlerInterceptor.postHandle
   ▼
HttpMessageConverter / ViewResolver  ── sérialise en JSON ou rend la view
   ▼
HandlerInterceptor.afterCompletion → Response ──▶ client
```

1. **Container + filters** — Tomcat remet la requête à la chaîne de `Filter`. Les Filters (y compris Spring Security) sont la couche la plus externe et peuvent bloquer ou envelopper la requête avant que MVC ne la voie.
2. **DispatcherServlet** — le front controller qui orchestre tout ce qui se trouve en dessous.
3. **HandlerMapping** — détermine quelle méthode de controller traite l'URL + la méthode.
4. **`preHandle`** — les `HandlerInterceptor` s'exécutent avant le controller (vérifications d'auth, logging, mesure de temps) ; retourner `false` arrête la requête.
5. **Argument resolution** — `@PathVariable`, `@RequestParam` et `@RequestBody` (via `HttpMessageConverter`) sont bindés et validés.
6. **Controller** — votre méthode `@RestController` exécute la logique métier et retourne un object ou une `ResponseEntity`.
7. **`postHandle`**, puis la valeur de retour est sérialisée par un `HttpMessageConverter` (JSON via Jackson) ou une view est rendue par un `ViewResolver`.
8. **`afterCompletion`** s'exécute après que la response a été committée ; `@ExceptionHandler`/`@ControllerAdvice` gèrent les exceptions en chemin.

```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 = court-circuit
    }
}

// 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. sérialisé en JSON
    }
}
```

## Pourquoi c'est important

Le cycle de vie de Spring possède deux couches d'extension distinctes que les recruteurs adorent sonder : les **Filters** (au niveau servlet, les plus externes — là où réside Spring Security) et les **Interceptors** (au niveau Spring MVC, autour du controller). Connaître l'ordre — filters, DispatcherServlet, mapping, interceptor `preHandle`, binding des arguments, controller, message conversion, `afterCompletion` — vous indique où placer l'authentification par rapport au logging, pourquoi un Security filter rejette une requête avant l'exécution de tout interceptor ou controller, et comment `@ControllerAdvice` centralise la gestion des exceptions sur tout le flux.

Les étapes

Pourquoi c'est important

Questions connexes