스프링 MVC - 1편 - 스프링 MVC 기본 기능 - (11) 요청 매핑 헨들러 어뎁터 구조

인프런 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술편을 학습하고 정리한 내용 입니다.

HTTP 메시지 컨버터는 스프링에서 어디에서 쓰일까?

스프링 MVC 구조

다음 그림에서는 알 수가 없다.

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

RequestMappingHandlerAdapter 동작 방식

ArgumentResolver

@Controller 애노테이션 기반의 컨트롤러는 파라미터로 매우 많은 걸 사용할 수 있다. HttpServletRequest, Model, @RequestParam, @ModelAttribute 등등 이런 것들..

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

애노테이션 기반 컨트롤러를 처리하는 RequestMappingHandlerAdapter는 바로 이 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;  
}

동작 방식

1. ArgumentResolver의 supportsParameter()를 호출해서 해당 파라미터를 지원하는지 체크
2. 지원 한다면 resolveArgument()를 호출해서 실제 객체 생성.
3. 생성된 객체를 컨트롤러 호출 시 넘김

그리고 원한다면 직접 이 인터페이스를 확장해서 원하는 ArgumentResolver를 만들 수도 있다.

실제 확장하는 예제는 향후 로그인 처리에서 진행해 볼 수 있을 것.

ReturnValueHandler

HandlerMethodReturnValueHandler를 줄여서 ReturnValueHandler라고 부른다. ArgumentResolver와 비슷한데, 이것은 응답 값을 변환하고 처리한다.

컨트롤러에서 String으로 뷰 이름을 반환해도, 동작하는 이유가 바로 ReturnValueHandler 덕분이다. 어떤 종류들이 있는지 살짝 코드로 확인만 해보자.

public interface HandlerMethodReturnValueHandler {  
    boolean supportsReturnType(MethodParameter returnType);  
  
    void handleReturnValue(@Nullable Object returnValue, MethodParameter returnType, ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception;  
}

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

참고 : 가능 응답 값 목록은 다음 공식 메뉴얼을 확인해 보자.

HTTP 메시지 컨버터

HTTP 메시지 컨버터를 사용하는 @RequestBody도 컨트롤러가 필요로 하는 파라미터의 값에 사용된다. @ResponseBody의 경우도 컨트롤러의 반환 값을 이용한다.

요청의 경우 @RequestBody를 처리하는 ArgumentResolver가 있고, HttpEntity를 처리하는 ArgumentResolver가 있다. 이 ArgumentResolver들이 HTTP 메시지 컨버터를 사용해서 필요한 객체를 생성하는 것이다.

HttpEntity를 처리하는 클래스를 가보면 다음과 같이 resolveArgument메서드가 있다. 이걸 또 타보면

복잡한 코드를 볼 수 있다.

스프링 버전마다 다를 수 있는데, 핵심은

반복문을 통해 등록된 메시지 컨버터들을 순회하면서, 해당 컨버터가 요청 본문의 컨텐츠 타입을 지원하는지 확인하고, 지원할 경우 해당 컨버터를 사용하여 요청 본문을 읽어드린다.

응답의 경우 @ResponseBody와 HttpEntity를 처리하는 ReturnValueHandler가 있다. 그리고 여기에서 HTTP 메시지 컨버터를 호출해서 응답 결과를 만든다.

스프링 MVC는 @Request @Response가 있으면 RequestResponseBodyMethodProcessor() HttpEntity가 있으면 HttpEntityMethodProcessor()fmf tkdydgksek.

참고
HttpMessageConverter를 구현한 클래스를 한번 확인해보자.

별의 별 컨버터들이 다 있다.

확장

스프링은 다음을 모두 인터페이스로 제공한다. 따라서 필요하면 언제든지 기능을 확장할 수 있다.

• HandlerMethodArgumentResolver
• HandlerMethodReturnValueHandler
• HttpMessageConverter

스프링이 필요한 대부분의 기능을 제공하기 때문에 실제 기능을 확장할 일이 많지 않다. 기능 확장은 WebMvcConfigurer를 상속 받아서 스프링 빈으로 등록하면 된다.

실제 자주 사용하지는 않으니 실제 기능 확장이 필요할 때 알아보자.

WebMvcConfigurer 확장

@Bean public WebMvcConfigurer webMvcConfigurer() {
	return new WebMvcConfigurer() { 
		@Override 
		public void addArgumentResolvers(List resolvers) {
			 //... 
		} 
		@Override 
		public void extendMessageConverters(List> converters) { 
			//... 
		} 
	}; 
}