스프링 부트 핵심 가이드 - 스프링 동작 방식

이건희·2024년 2월 22일
1

스프링 부트의 동작 방식

웹 요청이 들어왔을 때

스프링 부트에서 spring-boot-starter-web 모듈을 사용하면 기본적으로 톰캣을 사용하는 스프링 MVC 구조를 기반으로 동작한다. 일반적인 웹 요청이 들어왔을 때 스프링 부트는 다음과 같이 동작한다.

이미지 출처 : https://djcho.github.io/springboot/spring-boot-chapter2-2/

  1. DispatcherServlet으로 요청(HttpServletRequest)이 들어오면 DispatcherServlet은 핸들러 매핑(Handler Mapping)을 통해 요청 URI에 매핑된 핸들러(Controller)를 탐색한다.
  1. 핸들러 어댑터(HandlerAdapter)로 컨트롤러를 호출한다.
  1. 핸들러 어댑터에 컨트롤러의 응답이 돌아오면 ModelAndView로 응답을 가공해 반환한다.
  1. 뷰 형식으로 리턴하는 컨트롤러를 사용할 때는 뷰 리졸버(Veiw Resolver)를 통해 뷰(View)를 받아 리턴한다.

Servlet은 클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술이다. 일반적으로 서블릿은 서블릿 컨테이너에서 관리하는데, 스프링에서는 톰캣이 WAS의 역할과 서블릿 컨테이너의 역할을 수행한다.

서블릿 컨테이너의 특징은 다음과 같다.

  • 서블릿 객체 생성, 초기화, 호출, 종료하는 생명주기 관리

  • 서블릿 객체는 싱들톤 패턴

  • 멀티스레딩 지원

스프링에서는 DispatcherServlet이 서블릿의 역할을 수행한다. 이를 정리하면 DispatcherServlet은 하나의 서블릿이며, 톰켓(서블릿 컨테이너)이 DispatcherServlet을 실행하고, 톰캣으로 HTTP 요청이 오면 이를 DispatcherServlet으로 전달하여 처리한다.

핸들러 매핑 인터페이스와 구현체

핸들러 매핑은 요청 정보를 기준으로 어떤 컨트롤러를 사용할지 선정하는 인터페이스이다. 핸들러 패밍 인터페이스는 여러 구현체를 가지며, 대표적인 구현체 클래스는 아래와 같다.

BeanNameUrlHandlerMapping

  • 빈 이름을 URL로 사용하는 매핑 전략

  • 빈을 정의할 때 슬래시(/)가 들어가면 매핑 대상이 된다.

  • Ex) @Bean("/hello")

ControllerClassNameHandlerMapping

  • URL과 일치하는 클래스 이름을 갖는 빈을 컨트롤러로 사용하는 전략

  • 이름 중 Controller를 제외하고 앞 부분에 작성된 suffix를 소문자로 매핑

SimpleUrlHadlerMapping

  • URL 패넡에 매핑된 컨트롤러를 사용하는 전략

DefaultAnnotationHandlerMapping

  • 어노테이션으로 URL과 컨트롤러를 매핑하는 방법

응답 반환

뷰 리졸버는 뷰의 렌더링 역할을 담당하는 뷰 객체를 반환한다.

위는 뷰를 사용하는 방식이다.

하지만 나도 그렇고 보통 뷰가 없는 REST 형식의 @ResposeBody를 사용할 땐 뷰 리졸버를 호출하지 않고 MessageConverter를 거쳐 JSON 형식으로 변환해서 응답한다.

@RestController를 사용하는 DispatcherServlet의 동작 방식

  • MessageConverter는 요청과 응답에 대해 Body 값을 변환하는 역할을 수행한다.

  • Content-Type을 참고해서 Converter를 선정한다.

REST API

REST 정의에 대해 많이 읽어봤지만 머리에 잘 각인이 되지 않았다. 근데 이 책을 보면서 어느정도 가닥이 잡힌 것 같다. REST란

  • 주고 받는 자원(Resource)에 이름을 규정하고 URI에 명시해 HTTP 메서드를 통해 해당 자원의 상태를 주고 받는 것을 의미한다.

REST의 정의가 위와 같으므로, REST API는 REST 아키텍처를 따르는 시스템/애플리케이션 인터페이스라고 볼 수 있다. 또한 REST 아키텍처를 구현하는 웹 서비스를 'RESTful하다' 라고 표현한다.

REST의 특징

유니폼 인터페이스

  • 일관된 인터페이스를 의미한다.

  • REST 서버는 HTTP 표준 전송 규약을 따르기 때문에 프로그램 언어와 상관 없이 플랫폼 및 기술에 종속되지 않고 여러 기술, 언어 등과 호환해 사용할 수 있다는 것을 의미한다.

무상태성

  • REST는 무상태성(stateless)이라는 특징을 가지는ㄷ, 이는 서버에 상태 정보를 따로 보관하거나 관리하지 않는다는 의미이다.

  • 서버는 클라이언트가 보낸 요청에 대해 세션이나 쿠키 정보를 별도로 보관하지 않는다.

캐시 가능성

  • REST는 HTTP 표준을 그대로 사용하므로 HTTP 캐싱 기능을 적용할 수 있다.

  • 이 기능을 사용하려면 요청과 응답이 모두 캐싱 가능한지 명시가 필요하다.

  • 캐싱이 가능한 경우 클라이언트에서 캐시에 저장해두고 같은 요청에 대해서는 해당 데이터를 가져와 사용한다.

레이어 시스템

  • REST 서버는 네트워크 상의 여러 계층으로 구성될 수 있다.

  • 하지만 서버의 복잡도와 관계 없이 클라이언트는 서버와 연결되는 포인트만 알면 된다.

클라이언트-서버 아키텍처

  • REST 서버는 API를 제공하고 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설계한다.

  • 이러한 구조 때문에 서로에 대해 의존성이 낮춰지게 된다.

profile
백엔드 개발자가 되겠어요

0개의 댓글