[스프링 웹 MVC 1편] 27. 요청 매핑 핸들러 어댑터 구조

HTTP 메세지 컨버터는 어디에서 사용되는것일까,

보면 핸들러 어댑터에서 컨트롤러에 필요한 파라미터를 어디선가 던져주어야 하는것으로 보이는데

 

이 모든 비밀은 애노테이션 기반의 컨트롤러, @RequestMapping을 처리하는 핸들러 어댑터인

RequestMappingHandlerAdapter에 있다.

 

 

Argument Resolver

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

HttpServletRequest, Model, @RequestParam, @ModelAttribute와 같은 애노테이션

@RequestBody와 HttpEntity 같은 HTTP 메세지를 처리하는 부분까지 매우 큰 유연함을 보이는데

이 이유는 ArgumentResolver 덕분이다.

 

동작 방식은 다음과 같다.

ArgumentResolver의 supportsParameter()를 호출하여 해당 파라미터를 지원하는지 체크하고,

지원하면 resolveArgument()를 호출해서 실제 객체를 생성하고 이 생성된 객체가 컨트롤러 호출시 넘어가게 되는 과정을 거친다.

 

원한다면 이 ArgumentResolver를 직접 만들 수도 있다. (로그인 처리에서 진행)

 

ReturnValueHandler

HandlerMethodReturnValueHandler를 줄여서 returnValueHandler라 부른다.

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

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

 

스프링은 10여개가 넘는 ReturnValueHandler 를 지원한다.

예) ModelAndView , @ResponseBody , HttpEntity , String

 

---

HTTP 메세지 컨버터 구조

HTTP 메세지 컨버터를 사용하는 @RequestBody도 컨트롤러가 필요로하는 파라미터의 값에 사용된다

@ResponseBody의 경우도 컨트롤러 반환값을 이용한다,

따라서 Argument Resolver가 Parameter로 넘겨야 할 객체를 생성하는 과정에서 HTTP Message Converter가 작동한다.

 

요청의 경우 - @RequestBody를 처리하는 Argument Resolver / HttpEntity를 처리하는 ArgumentResolver 별도 존재한다.

ArgumentResolvers들이 HTTP 메세지 컨버터를 사용해서 필요한 객체를 생성한다.

 

응답의 경우 - @ResponseBody와 HttpEntity를 처리하는 ReturnValueHandler가 있고

여기에서 HttpMessageConverter를 호출해서 응답결과를 만든다.

 

스프링 MVC는 @RequestBody @ResponseBody 가 있으면

RequestResponseBodyMethodProcessor (ArgumentResolver)

HttpEntity 가 있으면 HttpEntityMethodProcessor (ArgumentResolver)를 사용한다

 

스프링은 다음을 모두 인터페이스로 제공하기 때문에 필요에 따라 기능의 확장이 가능하다

1) HandlerMethodArgumentResolver

2) HandlerMethodReturnValueHandler

3) HttpMessageConverter

 

확장이 필요한 경우 WebMvcResolver를 통해 확장할 수 있다