Hvordan fungerer en requests livscyklus i Spring Boot?

Question

IT Interview Practice · Accepted Answer

I Spring Boot (Spring MVC) passerer en request gennem **servlet-containeren**, en kæde af **Filtre**, den centrale **`DispatcherServlet`**, derefter **interceptors** og din **`@Controller`**, og returværdien konverteres til HTTP-svaret.

## Faserne

```
Servlet container (Tomcat)
   ▼
Filter chain  ── (CharacterEncoding, Security, CORS, ...)
   ▼
DispatcherServlet  ── front controlleren
   ▼
HandlerMapping  ── find @Controller-metoden
   ▼
HandlerInterceptor.preHandle
   ▼
Argument resolvers  ── bind @RequestBody / @PathVariable / @RequestParam
   ▼
Controller method  ── din logik → returnerer object eller ResponseEntity
   ▼
HandlerInterceptor.postHandle
   ▼
HttpMessageConverter / ViewResolver  ── serialisér til JSON eller render view
   ▼
HandlerInterceptor.afterCompletion → Response ──▶ client
```

1. **Container + filtre** — Tomcat overdrager requesten til `Filter`-kæden. Filtre (inklusive Spring Security) er det yderste lag og kan blokere eller pakke requesten ind, før MVC ser den.
2. **DispatcherServlet** — front controlleren, der orkestrerer alt nedenunder.
3. **HandlerMapping** — afgør hvilken controller-metode der håndterer URL'en + metoden.
4. **`preHandle`** — `HandlerInterceptor`s kører før controlleren (auth-tjek, logging, timing); at returnere `false` stopper requesten.
5. **Argument-opløsning** — `@PathVariable`, `@RequestParam` og `@RequestBody` (via `HttpMessageConverter`) bindes og valideres.
6. **Controller** — din `@RestController`-metode kører forretningslogikken og returnerer et object eller `ResponseEntity`.
7. **`postHandle`**, derefter serialiseres returværdien af en `HttpMessageConverter` (JSON via Jackson), eller et view renderes af en `ViewResolver`.
8. **`afterCompletion`** kører efter svaret er committet; `@ExceptionHandler`/`@ControllerAdvice` håndterer undtagelser undervejs.

```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 = kortslutning
    }
}

// 6. controller
@RestController
class ItemController {
    @GetMapping("/items/{id}")            // 3. mapping
    ResponseEntity<Item> show(@PathVariable Long id) {  // 5. argument-opløsning
        return ResponseEntity.ok(service.find(id));      // 7. serialiseret til JSON
    }
}
```

## Hvorfor det betyder noget

Springs livscyklus har to distinkte udvidelseslag, som interviewere elsker at grave i: **Filtre** (servlet-niveau, yderst — hvor Spring Security bor) og **Interceptors** (Spring MVC-niveau, omkring controlleren). At kende rækkefølgen — filtre, DispatcherServlet, mapping, interceptor `preHandle`, argument-binding, controller, meddelelseskonvertering, `afterCompletion` — fortæller dig, hvor du skal placere authentication vs. logging, hvorfor et Security-filter afviser en request, før nogen interceptor eller controller kører, og hvordan `@ControllerAdvice` centraliserer undtagelseshåndtering på tværs af hele flowet.

Faserne

Hvorfor det betyder noget

Relaterede spørgsmål