როგორ მუშაობს მოთხოვნის სასიცოცხლო ციკლი Spring Boot-ში?

Question

IT Interview Practice · Accepted Answer

Spring Boot-ში (Spring MVC) მოთხოვნა გადის **servlet container**-ს, **Filter**-ების ჯაჭვს, ცენტრალურ **`DispatcherServlet`**-ს, შემდეგ **interceptor**-ებსა და თქვენს **`@Controller`**-ს, და დაბრუნებული მნიშვნელობა გარდაიქმნება HTTP response-ად.

## ეტაპები

```
Servlet container (Tomcat)
   ▼
Filter chain  ── (CharacterEncoding, Security, CORS, ...)
   ▼
DispatcherServlet  ── front controller
   ▼
HandlerMapping  ── პოვნა @Controller მეთოდის
   ▼
HandlerInterceptor.preHandle
   ▼
Argument resolvers  ── bind @RequestBody / @PathVariable / @RequestParam
   ▼
Controller method  ── თქვენი ლოგიკა → აბრუნებს object ან ResponseEntity
   ▼
HandlerInterceptor.postHandle
   ▼
HttpMessageConverter / ViewResolver  ── სერიალიზაცია JSON-ში ან view-ის რენდერი
   ▼
HandlerInterceptor.afterCompletion → Response ──▶ client
```

1. **Container + filter-ები** — Tomcat გადასცემს მოთხოვნას `Filter` ჯაჭვს. Filter-ები (მათ შორის Spring Security) ყველაზე გარე ფენაა და შეუძლიათ დაბლოკონ ან შეახვიონ მოთხოვნა, სანამ MVC მას დაინახავს.
2. **DispatcherServlet** — front controller, რომელიც ორკესტრირებს ყველაფერს ქვემოთ.
3. **HandlerMapping** — წყვეტს, controller-ის რომელი მეთოდი ამუშავებს URL + method-ს.
4. **`preHandle`** — `HandlerInterceptor`-ები სრულდება controller-ამდე (auth შემოწმებები, logging, დროის გაზომვა); `false`-ის დაბრუნება აჩერებს მოთხოვნას.
5. **Argument-ის გადაწყვეტა** — `@PathVariable`, `@RequestParam` და `@RequestBody` (`HttpMessageConverter`-ის მეშვეობით) იბაინდება და ვალიდირდება.
6. **Controller** — თქვენი `@RestController` მეთოდი ასრულებს ბიზნეს-ლოგიკას და აბრუნებს object-ს ან `ResponseEntity`-ს.
7. **`postHandle`**, შემდეგ დაბრუნებულ მნიშვნელობას სერიალიზებს `HttpMessageConverter` (JSON Jackson-ის მეშვეობით) ან view-ს არენდერებს `ViewResolver`.
8. **`afterCompletion`** სრულდება response-ის commit-ის შემდეგ; `@ExceptionHandler`/`@ControllerAdvice` ამუშავებს გამონაკლისებს გზადაგზა.

```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 = გზის შეჩერება
    }
}

// 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. სერიალიზებული JSON-ში
    }
}
```

## რატომ არის ეს მნიშვნელოვანი

Spring-ის სასიცოცხლო ციკლს აქვს ორი განსხვავებული გაფართოების ფენა, რომელთა გამოკვლევაც უყვართ ინტერვიუერებს: **Filter**-ები (servlet-ის დონეზე, ყველაზე გარე — სადაც Spring Security ცხოვრობს) და **Interceptor**-ები (Spring MVC-ის დონეზე, controller-ის გარშემო). თანმიმდევრობის ცოდნა — filter-ები, DispatcherServlet, mapping, interceptor `preHandle`, argument-ის binding, controller, message-ის კონვერსია, `afterCompletion` — გეუბნებათ, სად განათავსოთ ავთენტიფიკაცია logging-თან შედარებით, რატომ უარყოფს Security filter მოთხოვნას ნებისმიერ interceptor-ის ან controller-ის გაშვებამდე, და როგორ ახდენს `@ControllerAdvice` გამონაკლისების დამუშავების ცენტრალიზებას მთელ ნაკადში.

ეტაპები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები