Como funciona o ciclo de vida de uma requisição no Spring Boot?

Question

IT Interview Practice · Accepted Answer

No Spring Boot (Spring MVC), uma requisição passa pelo **servlet container**, uma cadeia de **Filters**, o **`DispatcherServlet`** central, depois pelos **interceptors** e pelo seu **`@Controller`**, e o valor de retorno é convertido na resposta HTTP.

## As etapas

```
Servlet container (Tomcat)
   ▼
Filter chain  ── (CharacterEncoding, Security, CORS, ...)
   ▼
DispatcherServlet  ── o front controller
   ▼
HandlerMapping  ── encontra o método @Controller
   ▼
HandlerInterceptor.preHandle
   ▼
Argument resolvers  ── bind @RequestBody / @PathVariable / @RequestParam
   ▼
Controller method  ── sua lógica → retorna objeto ou ResponseEntity
   ▼
HandlerInterceptor.postHandle
   ▼
HttpMessageConverter / ViewResolver  ── serializa para JSON ou renderiza a view
   ▼
HandlerInterceptor.afterCompletion → Response ──▶ client
```

1. **Container + filters** — o Tomcat entrega a requisição para a cadeia de `Filter`. Os Filters (incluindo o Spring Security) são a camada mais externa e podem bloquear ou envolver a requisição antes de o MVC a ver.
2. **DispatcherServlet** — o front controller que orquestra tudo abaixo.
3. **HandlerMapping** — resolve qual método de controller trata a URL + o método.
4. **`preHandle`** — os `HandlerInterceptor`s rodam antes do controller (verificações de auth, logging, medição de tempo); retornar `false` interrompe a requisição.
5. **Resolução de argumentos** — `@PathVariable`, `@RequestParam` e `@RequestBody` (via `HttpMessageConverter`) são bindados e validados.
6. **Controller** — seu método `@RestController` roda a lógica de negócio e retorna um objeto ou `ResponseEntity`.
7. **`postHandle`**, então o valor de retorno é serializado por um `HttpMessageConverter` (JSON via Jackson) ou uma view é renderizada por um `ViewResolver`.
8. **`afterCompletion`** roda depois que a resposta é confirmada (commit); `@ExceptionHandler`/`@ControllerAdvice` tratam exceções ao longo do caminho.

```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 o fluxo
    }
}

// 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. serializado para JSON
    }
}
```

## Por que isso importa

O ciclo de vida do Spring tem duas camadas de extensão distintas que os entrevistadores adoram sondar: **Filters** (nível de servlet, mais externos — onde vive o Spring Security) e **Interceptors** (nível de Spring MVC, em torno do controller). Conhecer a ordem — filters, DispatcherServlet, mapping, `preHandle` do interceptor, binding de argumentos, controller, conversão de mensagem, `afterCompletion` — diz onde colocar autenticação versus logging, por que um filtro de Security rejeita uma requisição antes de qualquer interceptor ou controller rodar, e como o `@ControllerAdvice` centraliza o tratamento de exceções em todo o fluxo.

As etapas

Por que isso importa

Perguntas relacionadas