인프런 강의 38일차.

 - 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 1 (김영한 강사님)

 - 서블릿, JSP, MVC 패턴

 - 서블릿으로 1차 구현

   -> 서블릿으로 구현했을 때 불편한 점 개선을 위해 JSP로 2차 구현

   -> JSP로도 불편한 점을 개선하기 위해 MVC 패턴으로 3차 구현

 - 스프링 프로젝트 시작

   -> 스프링 기본기능 이해

   -> 스프링 MVC 웹페이지 만들기

4. 스프링 MVC - 기본 기능

 4.12 HTTP 메시지 컨버터

  > 뷰 템플릿으로 HTML을 생성해서 응답하는 것이 아니라, HTTP API처럼 JSON 데이터를 HTTP 메시지 바디에서 직접 읽거나 쓰는 경우 HTTP 메시지 컨버터를 사용하면 편리하다.

  * HTTP 메시지 컨버터를 설명하기 전에 잠깐 과거로 돌아가서 스프링 입문 강의에서 설명했던 내용을 살펴보자

   - HTTP의 BODY에 문자 내용을 직접 반환

   - viewResolver 대신에 HttpMessageConverter 가 동작

   - 기본 문자처리: StringHttpMessageConverter

   - 기본 객체처리: MappingJackson2HttpMessageConverter 

   - byte 처리 등등 기타 여러 HttpMessageConverter가 기본으로 등록되어 있음

  * 응답의 경우 클라이언트의 HTTP Accept 해더와 서버의 컨트롤러 반환 타입 정보 둘을 조합해서 HttpMessageConverter 가 선택된다.

  * 스프링 MVC는 다음의 경우에 HTTP 메시지 컨버터를 적용한다.

   - HTTP 요청: @RequestBody , HttpEntity(RequestEntity) ,

   - HTTP 응답: @ResponseBody , HttpEntity(ResponseEntity) ,

  > HTTP 메시지 컨버터 인터페이스

   - org.springframework.http.converter.HttpMessageConverter

   - JsonConverter, StringConverter 등 다양한 타입을 처리해야하므로 인터페이스로 되어있음

   - HTTP 메시지 컨버터는 HTTP 요청, HTTP 응답 둘 다 사용된다.

   - canRead() , canWrite() : 메시지 컨버터가 해당 클래스, 미디어타입을 지원하는지 체크

   - read() , write() : 메시지 컨버터를 통해서 메시지를 읽고 쓰는 기능

  * 스프링 부트 기본 메시지 컨버터

   - 0 = ByteArrayHttpMessageConverter

   - 1 = StringHttpMessageConverter

   - 2 = MappingJackson2HttpMessageConverter

   - 스프링 부트는 다양한 메시지 컨버터를 제공하는데, 대상 클래스 타입과 미디어 타입(컨텐츠타입) 둘을 체크해서 사용여부를 결정한다. 만약 만족하지 않으면 다음 메시지 컨버터로 우선순위가 넘어간다

 * 주요 컨버터 3가지

 > 1 = ByteArrayHttpMessageConverter : byte[] 데이터를 처리한다.

  - 클래스 타입: byte[] , 미디어타입: */* 

  - 요청 예) '@RequestBody byte[] data'

  - 응답 예) '@ResponseBody return byte[]',  쓰기 미디어타입 'application/octet-stream'

 > 2 = StringHttpMessageConverter : String 문자로 데이터를 처리한다

  - 클래스 타입: String , 미디어타입: */*

  - 요청 예) '@RequestBody String data'

  - 응답 예) '@ResponseBody return "ok" ', 쓰기 미디어타입 'text/plain'

 > 3 = MappingJackson2HttpMessageConverter : application/json

  - 클래스 타입: 객체 또는 HashMap , 미디어타입 application/json 관련

  - 요청 예) '@RequestBody HelloData data'

  - 응답 예) '@ResponseBody return helloData', 쓰기 미디어타입 'application/json 관련'

/**
 * 동작 컨버터 체크
 * 1. 클래스 체크 : Stirng -> 0순위인 byte 컨버터는 대상이 아니므로 false, 1순위인 String 컨버터가 true
 * 2. 미디어타입 체크 : application/json -> String 컨버터는 */* 미디어타입을 허용하므로 true
 * 최종 결과 : StringHttpMessageConverter가 동작함
 */
 
content-type: application/json
@RequestMapping
void hello(@RequetsBody String data) {}

/**
 * 동작 컨버터 체크
 * 1. 클래스 체크 : HelloData -> 0순위인 byte 컨버터는 대상이 아니므로 false, 1순위인 String 컨버터도 false, 2순위인 Jackson 컨버터(객체 또는 해쉬맵)는 true
 * 2. 미디어타입 체크 : application/json -> Jackson 컨버터는 application/json 미디어타입을 허용하므로 true
 * 최종 결과 : MappingJackson2HttpMessageConverter 동작
 */

content-type: application/json
@RequestMapping
void hello(@RequetsBody HelloData data) {}

/**
 * 동작 컨버터 체크
 * 1. 클래스 체크 : HelloData -> 0순위인 byte 컨버터는 대상이 아니므로 false, 1순위인 String 컨버터도 false, 2순위인 Jackson 컨버터(객체 또는 해쉬맵)는 true
 * 2. 미디어타입 체크 : application/json -> Jackson 컨버터는 application/json 미디어타입을 허용하므로 false
 * 최종 결과 : 어떠한 컨버터도 동작하지 않는다.
 */

content-type: text/html
@RequestMapping
void hello(@RequetsBody HelloData data) {}

 * HTTP 요청 데이터 읽기

  > HTTP 요청이 오고, 컨트롤러에서 @RequestBody , HttpEntity 파라미터를 사용한다.

  > 메시지 컨버터가 메시지를 읽을 수 있는지 확인하기 위해 canRead() 를 호출한다.

   - 대상 클래스 타입을 지원하는가 (예. @RequestBody 의 대상 클래스 : byte[] , String , HelloData )

   - HTTP 요청의 Content-Type 미디어 타입을 지원하는가. (예. text/plain , application/json , */* )

  > canRead() 조건을 만족하면 read() 를 호출해서 객체 생성하고, 반환한다

 * HTTP 응답 데이터 생성

  > 컨트롤러에서 @ResponseBody , HttpEntity 로 값이 반환된다

  > 메시지 컨버터가 메시지를 쓸 수 있는지 확인하기 위해 canWrite() 를 호출한다.

   - 대상 클래스 타입을 지원하는가 (예. return의 대상 클래스 : byte[] , String , HelloData ) 

   - HTTP 요청의 Accept 미디어 타입을 지원하는가. (더 정확히는 @RequestMapping 의 produces ) (예. text/plain , application/json , */* )

  > canWrite() 조건을 만족하면 write() 를 호출해서 HTTP 응답 메시지 바디에 데이터를 생성한다.

 4.13 요청 매핑 헨들러 어뎁터 구조

  > 그렇다면 대체 HTTP 메시지 컨버터는 스프링 MVC 어디쯤에서 사용되는 것일까?

  * 모든 비밀은 애노테이션 기반의 컨트롤러, 그러니까 @RequestMapping 을 처리하는 핸들러 어댑터인 RequestMappingHandlerAdapter (요청 매핑 헨들러 어뎁터)에 있다

 * ArgumentResolver

  > 애노테이션 기반의 컨트롤러는 매우 다양한 파라미터를 사용할 수 있었다.

  > HttpServletRequest , Model 은 물론이고, @RequestParam , @ModelAttribute 같은 애노테이션 그리고 @RequestBody , HttpEntity 같은 HTTP 메시지를 처리하는 부분까지 매우 큰 유연함을 보여주었다.

  > 이렇게 파라미터를 유연하게 처리할 수 있는 이유가 바로 ArgumentResolver 덕분이다.

  > 애노테이션 기반 컨트롤러를 처리하는 RequestMappingHandlerAdaptor 는 바로 이 ArgumentResolver 를 호출해서 컨트롤러(핸들러)가 필요로 하는 다양한 파라미터의 값(객체)을 생성한다.

  > 그리고 이렇게 파리미터의 값이 모두 준비되면 컨트롤러를 호출하면서 값을 넘겨준다

  > 스프링은 30개가 넘는 ArgumentResolver 를 기본으로 제공한다.

  > 정확히는 HandlerMethodArgumentResolver 인데 줄여서 ArgumentResolver 라고 부른다.

public interface HandlerMethodArgumentResolver {
    boolean supportsParameter(MethodParameter parameter);
    @Nullable
    Object resolveArgument(MethodParameter parameter, @Nullable
            ModelAndViewContainer mavContainer,
                           NativeWebRequest webRequest, @Nullable WebDataBinderFactory
                                   binderFactory) throws Exception;
}

  - 동작방식 : ArgumentResolver 의 supportsParameter() 를 호출해서 해당 파라미터를 지원하는지 체크하고, 지원하면 resolveArgument() 를 호출해서 실제 객체를 생성한다. 그리고 이렇게 생성된 객체가 컨트롤러 호출시 넘어가는 것이다

  > ReturnValueHandler : HandlerMethodReturnValueHandler 를 줄여서 ReturnValueHandle 라 부른다

  > ArgumentResolver 와 비슷한데, 이것은 응답 값을 변환하고 처리한다

  > 컨트롤러에서 String으로 뷰 이름을 반환해도, 동작하는 이유가 바로 ReturnValueHandler 덕분이다. 

  > 스프링은 10여개가 넘는 ReturnValueHandler 를 지원한다. (ModelAndView, @ResponseBody, HttpEntity, String)