Spring MVC Internals

4.1 Spring MVC nedir?

Spring MVC, HTTP isteklerini Java metodlarına bağlayan web framework katmanıdır. Biz çoğu zaman @RestController, @GetMapping, @PostMapping, @RequestBody gibi annotation’ları görürüz. Bunlar kullanım tarafıdır. Bu modülde kullanımın arkasındaki mekanizmaya bakacağız.

En basit haliyle Spring MVC şunu yapar: Gelen isteğin URL ve HTTP method bilgisine bakar, uygun controller methodunu bulur, method parametrelerini hazırlar, methodu çağırır ve dönen cevabı HTTP response’a çevirir.

4.2 DispatcherServlet: ana giriş kapısı

DispatcherServlet, Spring MVC’nin merkezindeki servlet’tir. Servlet container, yani çoğunlukla embedded Tomcat, HTTP isteğini alır ve Spring MVC’ye teslim eder. Spring MVC tarafında bu isteği ilk karşılayan parça DispatcherServlet olur.

Bu sınıfın görevini bir resepsiyon görevlisi gibi düşünebilirsin. İstek gelir, resepsiyon isteğin ne olduğunu anlamaya çalışır, doğru kişiye yönlendirir, cevap gelince de client’a geri döndürür. Kendisi business logic yazmaz; koordinasyon yapar.

Spring Boot kullandığımızda DispatcherServlet bean’ini genellikle biz oluşturmayız. spring-boot-starter-web dependency’si geldiğinde Spring Boot MVC auto-configuration üzerinden gerekli web altyapısını hazırlar. Modül 01’de gördüğümüz auto-configuration burada gerçek karşılığını bulur.

4.3 HandlerMapping: hangi URL hangi metoda gider?

Bir request geldiğinde Spring’in ilk kritik sorusu şudur: Bu URL ve HTTP method hangi controller metoduna ait? İşte HandlerMapping bu soruyu cevaplar.

Mesela aşağıdaki controller metodunu düşünelim:

@RestController
@RequestMapping("/api/accounts")
public class AccountController {

    @GetMapping("/{iban}")
    public AccountResponse getAccount(@PathVariable String iban) {
        return accountService.getAccount(iban);
    }
}

GET /api/accounts/TR001 isteği geldiğinde Spring MVC bu mapping bilgisini önceden çıkarmış olur. Runtime’da URL ve HTTP method bilgisine bakarak bu request’in getAccount metoduna gitmesi gerektiğini bulur.

4.4 HandlerAdapter: bulunan handler nasıl çalıştırılır?

HandlerMapping doğru handler’ı bulur, ama onu doğrudan çalıştırmaz. Çünkü Spring MVC’de farklı handler türleri olabilir. Controller methodu, functional endpoint, eski tip controller yapıları gibi farklı modelleri çalıştırmak için araya HandlerAdapter girer.

Günlük Spring Boot REST API geliştirmesinde en çok gördüğümüz model annotation tabanlı controller methodlarıdır. Bu durumda Spring, controller metodunun parametrelerini tek tek çözmek zorundadır. @PathVariable, @RequestParam, @RequestBody, @RequestHeader gibi parametrelerin her biri farklı kaynaklardan gelir.

4.5 HttpMessageConverter: JSON nerede devreye girer?

Spring MVC’de request body’nin Java objesine dönüşmesi ve Java objesinin JSON response’a dönüşmesi HttpMessageConverter mekanizmasıyla yapılır. REST API geliştirirken en sık kullanılan converter genellikle Jackson tabanlı JSON converter’dır.

Örneğin client aşağıdaki JSON’u gönderir:

{
  "iban": "TR001",
  "initialBalance": 1000
}

Controller metodunda ise bunu Java objesi olarak görürüz:

@PostMapping
public ResponseEntity<AccountResponse> createAccount(
        @RequestBody AccountCreateRequest request) {
    return ResponseEntity.ok(accountService.createAccount(request));
}

Bu dönüşümün manuel olarak bizim tarafımızdan yapılmaması büyük kolaylıktır. Ama bu kolaylık görünmez olduğunda bazı problemleri anlamak zorlaşır: yanlış tarih formatı, beklenmeyen enum değeri, eksik field, büyük/küçük harf farkı, response’ta istenmeyen alanların çıkması gibi konular çoğu zaman JSON dönüşüm katmanıyla ilgilidir.

4.6 Argument Resolver: controller parametresini kim hazırlıyor?

Spring MVC’nin en güçlü ama çoğu zaman fark edilmeyen parçalarından biri HandlerMethodArgumentResolver mekanizmasıdır. Controller metoduna yazdığımız parametrelerin nasıl üretileceğini bu mekanizma belirler.

Örneğin @PathVariable String iban parametresi URL’den gelir. @RequestBody AccountCreateRequest request parametresi JSON body’den gelir. Peki kendi özel parametremizi üretmek istersek ne olur?

MiniBank’ta her request’te header’dan gelen kullanıcı bilgisini controller metodunda doğrudan almak isteyebiliriz:

@GetMapping("/me/accounts")
public List<AccountResponse> myAccounts(CurrentUser currentUser) {
    return accountQueryService.findAccountsOf(currentUser.customerNo());
}

Burada CurrentUser nesnesini controller içinde manuel header okuyarak oluşturmak istemiyoruz. Bu iş her controller’da tekrarlanırsa kod kirlenir. Bunun yerine Spring MVC’ye şunu öğretiriz: “Eğer controller metodunda CurrentUser parametresi görürsen, bunu request header’dan üret.”

Bu CurrentUser deseni şimdilik header’dan okuyor; Modül 08’de security devreye girdiğinde aynı parametre JWT’den doğrulanmış kullanıcıyla beslenecek, yani controller kodu hiç değişmeden gerçek kimliğe bağlanacak.

4.7 Filter, Interceptor ve Argument Resolver: request akışında kim nerede?

Şimdiye kadar baktığımız parçalar (HandlerMapping, HandlerAdapter, converter, argument resolver) hep DispatcherServlet’in içinde çalıştı. Ama request controller’a ulaşana kadar iki ek katmandan daha geçer: servlet Filter ve HandlerInterceptor. Mini Sözlük’te bunlara değindik; burada akıştaki yerlerini netleştiriyoruz.

Üçünün arasındaki temel fark, request hattındaki konumlarıdır. Filter en dışta, servlet seviyesinde durur ve DispatcherServlet’i bile sarar. Interceptor ise DispatcherServlet’in içinde, ama handler çalışmadan hemen önce ve sonra devreye girer. Argument resolver ise en içeride, tam olarak handler parametreleri hazırlanırken çalışır.

MiniBank’ta her ikisinin de gerçek örneği var. CorrelationIdFilter bir servlet Filter’dır; DispatcherServlet’e gelmeden önce her request’e bir correlation id atar. CurrentUser ise argument resolver ile handler parametresi olarak üretilir:

@Component
public class CorrelationIdFilter extends OncePerRequestFilter {

    public static final String CORRELATION_ID_HEADER = "X-Correlation-Id";

    @Override
    protected void doFilterInternal(
            HttpServletRequest request,
            HttpServletResponse response,
            FilterChain filterChain) throws ServletException, IOException {
        // DispatcherServlet'ten ÖNCE: en dış katman
        String correlationId = resolveCorrelationId(request);
        response.setHeader(CORRELATION_ID_HEADER, correlationId);
        filterChain.doFilter(request, response);
    }
}

Buraya kadar konuştuğumuz akış REST tarafıdır: handler bir DTO döner, @ResponseBody ve HttpMessageConverter bunu JSON’a çevirir (4.5). Klasik MVC’de ise handler bir ModelAndView döner; yani hangi view’ın render edileceği ve hangi model verisinin kullanılacağı bilgisini taşır. Sözlükte gördüğümüz ModelAndView tam olarak burada yaşar. MiniBank REST API olduğu için biz ModelAndView yerine converter yolunu kullanıyoruz, ama ikisi de aynı DispatcherServlet akışının iki ucudur.