스프링 웹 mvc

[Jeonwoojae]

• 스프링 프레임워크는 spring-webmvc 모듈을 제공하며 이외에도 다양한 기능을 제공하는 spring-web모듈이 있다.
• API인터페이스는 gRPC나 AVRO 등 여러 인터페이스를 이용하여 개발할 수 있는데 REST-API는 HTTP프로토콜 기반이며 JSON형식의 유연한 데이터 구조로 범용적이다.

HTTP 요청 메시지

• 요청 라인으로 시작하며 헤더와 바디로 구성된다.
  • GET /hotel.html?id=129 HTTP/1.1
  • GET은 메서드의 종류, /hotel~은 리소스를 의미한다.
  • HTTP리소스는 HTTP 요청 대상을 의미하며 멀티미디어 파일도 될 수 있다.
  • URI(Uniform Resource Identifier)로 구분된다.
  • 쿼리 스트링으로 파라미터에 특정 값을 전달한다.
  • HTTP/1.1은 프로토콜 버전을 의미한다.
• 바디를 사용하는 예는 메일을 보낼 때 첨부 파일을 업로드 하는 경우

HTTP 응답 메시지

• 상태 라인으로 시작하며 헤더와 바디로 구성된다.

HTTP 특징

• 다른 프로토콜과 비교하면 비연결성과 무상태 특징이 있다.
• 비연결성
  • HTTP 프로토콜이 서버와 클라이언트 사이에 커넥션을 유지할 필요 없이 데이터를 송수신 할 수 있음
  • 단점
  • TCP 커넥션을 서버와 클라이언트 사이에 생성하려면 3-way-handshake 과정을 거쳐야 하며 리소스가 많이 필요하다.
  • HTTP/1.1부터 keep-alive를 지원하여 일정 시간 동안 커넥션을 유지할 수 있다.
  • 단점
  • 커넥션을 항상 유지할 필요가 없다.
    • 커넥션을 유지한다면 모든 요청이 한 서버로 전송되어 부하가 집중된다. 아키텍처로 해결할 수는 있음
  • 매번 커넥션을 맺기 때문에 L4나 L7같은 로드 밸런서가 있으면 서버가 균등하게 처리할 수 있다
• 무상태
  • 서버에 여러 요청을 해도 각 요청은 하나씩 독립적으로 처리된다.
  • 서버 사이에 데이터를 공유하지 않아도된다.
  • 인증과 인가에서 문제
  • 이를 해결하기 위해 쿠키나 세션 기능 제공

스프링 웹 MVC 프레임워크

• 자바 플랫폼 엔터프라이즈 에디션(Java EE 또는 J2EE) 표준인 서블릿을 포함
• WAS를 이용하여 웹 서비스를 한다.

  서블릿 3.0 : 비동기 서블릿 지원 서블릿 3.1 : 비차단 방식의 IO 기능 지원 서블릿 5.0 : HTTP 2.0 기반의 기능 지원

• 서블릿 애플리케이션은 설정파일(web.xml)에 서블릿 정보를 작성하고 톰캣이 실행할 때 이를 읽어 서블릿 애플리케이션을 로딩
• 설정파일에서 어떤 애플리케이션이 어떤 URL을 처리할지 설정한다.
• 톰캣은 요청에 적절한 서블릿 애플리케이션을 실행한다.

  GET /hotel?id=129 HTTP/1.1
  Host : www.springtour.com
  Accept : text/html

  

• 서블릿에서 두 객체를 이용하여 요청과 응답을 처리
• Accept 헤더는 콘텐츠 타입을 알려준다.
  • request 객체의 getHeader()로 확인 가능
  • 응답의 Content-type 또한 response 객체의 setHeader()로 지정 가능
• 전통적인 서블릿 애플리케이션
  • 지금 예시와 같이 데이터 로직과 html 코드가 하나의 클래스에서 담당.
  • 의도치 않은 수정이 일어나고 유지보수가 어려움

[Jeonwoojae]

• 전통적인 mvc는 각 기능에 따라 클래스를 분리했지만 의존성은 그대로 가지고 있다.
• 스프링 mvc는 의존성 문제를 해결하기 위해 IoC 컨테이너를 제공한다.
  • 역할에 따라 스테레오 타입 어노테이션을 사용하면 된다.
  • ApplicationContext에 스프링 빈으로 로딩되며 빈 사이의 의존 관계에 따라 스프링 빈을 주입한다.
• Dispatcher 서블릿이 스프링 mvc 프레임워크에서 지원하는 컴포넌트 중 하나로 전체 기능을 제어한다.
  • 사용자의 모든 요청을 우선적으로 처리
  • 요청 리소스에 따라 해당하는 컨트롤러에 요청 전달
  • 컨트롤러 빈은 구현한 스프링 빈들의 메서드 호출
  • 컨트롤러는 ModelAndView 객체로 UI를 처리할 수 있는 View를 찾아 컨트롤러가 리턴한 객체를 전달
• 개발자는 스테레오 타입 어노테이션을 선언한 클래스만 구현하면 나머지는 프레임워크가 제공하는 것이다.

[Jeonwoojae]

자세한 스프링 MVC 컴포넌트

1. 클라이언트의 모든 메시지는 DispatcherServlet이 처리한다.
2. DispatcherServlet은 요청 메시지의 요청 라인과 헤더를 파악한 후 어떤 컨트롤러의 메소드로 전달할지 HandlerMapping 컴포넌트의 메소드로 확인한다.
3. 요청에 적합한 컨트롤러 클래스에 전달하기 위해 전달 역할을 하는 HandlerAdapter에 전달한다.
4. HandlerAdapter는 해당하는 컨트롤러에 요청을 전달한다.
5. 컨트롤러는 개발자가 만든 비즈니스 로직을 실행한다. 이 로직은 개발자가 정의한 스프링 빈과 일반 자바 객체 조합으로 구성된다. 결과는 다시 컨트롤러로 전달되고 컨트롤러는 어떤 뷰로 전달할지 결정한다.
6. HandlerAdapter는 처리할 뷰와 뷰에 매핑할 데이터를 ModelAndView 객체에 포함하여 DispatcherServlet에 전달한다.
7. DispatcherServlet은 처리할 뷰 정보를 ViewResolver에 확인한다.
8. DispatcherServlet은 View에 데이터를 전달하고, View는 데이터를 HTML, XML 등 적합한 포멧으로 변환한다. 변환한 데이터를 DispatcherServlet으로 전달한다.
9. 변환된 데이터를 클라이언트에 전달한다.

HadlerAdapter : 이 컴포넌트는 사용자 HTTP 요청 메시지를 추상화한 HttpServletRequest 객체를 받아 요청을 처리하는 핸들러 객체를 조회하는 getHandler()메소드를 제공한다. 리턴받은 핸들러 객체는 HandlerExecutionChain이며, 어떤 컨트롤러 클래스의 메소드인지 알 수 있다. 스프링 부트 프레임워크 기본 설정으로 실행하면 RequestMappingHandlerMapping 구현체가 실행되어 @RequestMapping의 속성 정보를 로딩할 수 있다. HandlerAdapter : 사용자의 요청과 응답을 추상화 한 HttpServletRequest, HttpServletResponse 객체를 컨트롤러 메소드에 전달하는 오브젝트 어댑터 역할을 한다. ModelAndView를 리턴하는 handle() 메소드를 제공한다. @RequestMapping을 처리하는 RequestMappingHandlerMapping 구현체와 한쌍으로 RequestMappingHandlerAdapter 구현체를 많이 사용한다. ModelAndView : 컨트롤러에서 처리한 결과를 어떤 뷰에서 처리할지, 처리할 데이터를 포함한 클래스이다. ViewResolver : 문자열 기반 View 이름을 View 객체로 변경한다. 다양한 템플릿 뷰 엔진이 있으며 적합한 ViewResolver 구현체는 프레임워크에서 제공한다. 이 구현체를 스프링 빈으로 정의하면 된다.

[Jeonwoojae]

서블릿 스택과 스레드 모델

• 스프링 5.0부터 서블릿 모델을 사용한 서블릿 스택과 리액트 모델을 적용한 리액티브 스택 중 선택할 수 있다.
• 리액티브 스택은 서블릿보다 더 높은 처리량을 보여주는데 종료 시점을 기다리지 않고 바로 다른 기능을 수행하기 때문이다.
• 이벤트 루프 모델은 시스템 자원을 효율적으로 사용하지만 하나의 기능을 여러 이벤트로 분리해야 하나의 이벤트가 여러 스레드에서 실행될 수 있다.
• 서블릿 스택은 하나의 기능을 하나의 스레드에서만 동작하여 ThreadLocal같은 클래스도 사용할 수 있으며 비교적 간단하게 프로그래밍 할 수 있다.

스레드 풀과 어플리케이션 동작

• 클라이언트가 리소스를 서버에 요청하면 서버는 스레드 풀에서 스레드 하나가 요청과 응답을 처리하도록 할당한다
  • 스레드풀은 WAS가 기동되며 초기화
  • 사용자 요청마다 스레드를 만들면 비용이 비싸므로 스레드풀 사용
  • 스레드 개수는 유한하여 고갈되면 요청을 처리하지 못하거나 프로세스가 죽음
• 사용자 요청과 스레드의 생명주기가 일치하므로 쉽게 개발 및 운영할 수 있다.
  • Thread Per Request : 요청이 오면 스레드풀의 스레드로 요청 처리 후 스레드는 스레드풀로 반납
• 하나의 스레드에서 모든 객체의 메서드가 실행되므로 개발자가 스레드를 직접 다루지 않아도 된다.
  • 예외 처리 상황에서도 로그를 통해 에러 위치를 확인할 수 있다.

[Jeonwoojae]

spring-boot-starter-web 의존성 추가

• 의존성을 추가하게 되면 WebMvcAutoConfiguration이 실행되며 내부에 EnableWebMvcConfiguration과 WebMvcAutoConfigurationAdapter가 포함되어 있다.
• EnableWebMvcConfiguration은 RequestMappingHandler Mapping과 RequestMappingHadnlerAdapter 컴포넌트를 생성하고 관리한다.
• WebMvcAutoConfigurationAdapter는 WebMvcConfigurer를 구현하여 자동 설정한다.
  • 특히 HttpMessageConverter들을 설정한다.
• 설정이 끝나면 DispatcherServletAutoConfiguration 클래스가 실행되어 DispatcherServlet 객체를 생성하고 설정한다.

[Jeonwoojae]

REST-API를 설계 및 구현하는 세 가지 특성

1. 무상태성

   • REST-API는 HTTP프로토콜을 사용하는 API이므로 무상태성 또한 이어받는다.
   • 클라이언트는 서버와 커넥션을 맺고 응답하면 커넥션을 끊는 것을 이용하여 고가용성을 구축한다. 로드 밸런서를 사용해도 무상태성 덕분에 서비즈 중에도 서버를 증설하거나 축소하기 쉽다.
   • 이때 하나의 API가 하나의 기능을 완전히 실행해야 한다.
   • 상태를 저장해야 한다면 공용 데이터 저장소에 저장한다.
   • 서버에 저장한다면 데이터가 분산되어 사용자마다 서버를 할당해야한다.

2. 일관성

   • 같은 형태의 응답 메시지나 일관된 규칙으로 만들어진 HTTP 상태 코드를 정의해야 한다.
   • 규칙에 따라 어떤 정보를 리턴할지 예측할 수 있어야한다.

3. 멱등성

   • 멱등성이란 함수를 여러 번 적용한 결과와 한 번 적용한 결과가 같음을 의미한다.
   • GET 메소드는 안전한 메소드로 아무리 실행해도 리소스 상태가 변하지 않는다.
   • POST를 제외한 메소드들은 멱등성이 있어야 한다.
   • POST는 요청할 때마다 생성하면 된다.
   • PUT으로 boolean 속성을 변경하는 경우 반대로 업데이트 하도록 설계한다면, 사용자 여러 명이 짧은 시간 내에 false를 기대하며 요청했지만 데이터의 상태가 true가 될 수 있다.
   • DELETE로 삭제하는 과정에 서버에서는 삭제에 성공했지만 패킷 누락으로 클라이언트는 삭제된지 모르는 상황이다.
   • 결과를 못받은 클라이언트는 재시도하고 서버는 삭제되었기 때문에 오류를 리턴한다.
   • 멱등성을 만족한다면 모두 성공을 응답할 것이다.

[Jeonwoojae]

HttpMessageConverter

• REST-API 컨트롤러에서 객체를 리턴하면 View를 설정하지 않았음에도 JSON 형식으로 마셜링(marshalling)된다.
• @ResponseBody 어노테이션이 선언된 메소드가 리턴하는 객체는 메시지 컨버터 중 적합한 메시지 컨버터가 JSON으로 변경한다.
• HttpMessageConverter는 받은 MediaType 메시지를 clazz 타입으로 변경할 수 있는지 확인, 응답할 clazz 객체를 MediaType메시지로 변경할 수 있는지 확인, read로 사용자에게 받은 메시지(HttpInputMessage) 객체를 clazz객체로 변경 수행, write로 HttpOutputMessage 객체를 MediaType로 변경 수행한다.
• MediaType는 valueOf()메소드로 Content-type나 Accept 헤더를 파싱하여 MediaType 객체로 변환한다.
• canRead, canWrite로 적절한 메시지 컨버터를 찾는다.