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

HTTP 메시지 컨버터는 스프링 MVC 어느 부분에서 사용이 되는지 궁금할 수 잇다.

 

@RequestMapping을 처리하는 핸들러 어댑터인 RequestMappingHandlerAdapter(요청 매핑 핸들러 어뎁터에 있다.)

 

ArgumentResolver

• HttpServletRequest, Model @RequestParam, @ModelAttribute 같은 애노테이션
• @RequestBody, HttpEntity 같은 HTTP 메시지를 처리하는 부분까지 큰 유연함을 보여주었다.
• ArgumentResolver 덕택에 파라미터를 유연하게 처리할 수 있었다.

 

 

RequestMappingHandlerAdaptor는 ArgumentResolver를 호출해서 컨트롤러(핸들러)기 필요로 하는 여러 파라미터의 값을 생성해준다. 파라미터의 값이 모두 준비되면 컨트롤러를 호출해주고 값을 넘겨준다.

• 30개가 넘는 ArgumentResolver를 기본으로 제공해주고 어떤 종류가 있는지 보자.

 

 

HandlerMethodArgumentResolver(ArgumentResolver)에서 supportParameter를 열어보면 

컨트롤러가 받아야 될 파라미터 정보가 있으면 resolveArgument에서 객체를 만들어서 넘겨주는 것이다. 복잡하다.

 

 

 

ReturnValueHandler

엄청 많다.

• HandlerMethodReturnValueHandler를 줄여서 ReturnValueHandler라고 부르고
• ArgumentResolver와 비슷한데, 응답 값을 변환하고 처리해준다.

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

살짝 코드로 보면

 

 

 

 

HTTP 메시지 컨버터 위치

 

 

 

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

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

 

 

Request 요청같은 경우는 @RequestBody를 처리하는 ArgumentResolver가 있고, HttpEntity를 처리하는 

ArgumentResolver가 있다. ArgumentResolver들이 HTTP 메시지 컨버터를 사용해 필요한 객체를 생성하는 것이다.

 

Response 응답의 경우 @ResponseBody와 HttpEntity를 처리하는 ReturnValueHandler가 있다.

여기에 HTTP 메시지 컨버터를 호출해 응답 결과를 만든다.

 

 

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

RequestResponseBodyMethodProcessor(ArgumentResolver)

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

 

 

 

 

 

 

 

그리고 스프링은 다음을 모두 인터페이스로 제공을 한다. 즉 구현체를 넣어서 언제든지 확장할 수 있는 것이다.

• HandlerMethodArgumentResolver
• HandlerMethodReturnValueHandler
• HttpMessageConverter

 

스프링이 필요한 대부분의 기능을 제공하기 때문에 실제 기능을 확장할 일이 많지는 않다. 

기능 확장은 WebMvcConfigurer를 상속 받아서 스프링 빈으로 등록하면 된다. 

실제 자주 사용하지는 않으니 실제 기능 확장이 필요할 때 WebMvcConfigurer 를 검색해보자.

 

 

WebMvcConfigurer에 메서드가 다 들어있다.

스프링 빈으로 등록해주면 스프링이 자동으로 인식을 해준다.

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

 

 

 

간략하게 정리해보자.

로깅 파트에서

SLF4J 인터페이스
Logback 는 수많은 구현체중에 그 구현체이다.

 

@Slf4j : 롬복 사용 가능

 

그리고 로그가 출력되는 포멧 확인에서 레벨이 아래와 같이 있고

• LEVEL: TRACE > DEBUG > INFO > WARN > ERROR

 

개발 서버는 항상 로그를 남긴다.

• 개발 서버는 debug!
• 운영 서버는 info! 레벨로 사용하는게 좋다.

성능도 로그를 쓰는게 훨씬 더 빠르다.

 

 

 

 

그리고 API 스타일로 매핑할때는

 

회원 관리 API

• 회원 목록 조회: GET /users
• 회원 등록: POST /users
• 회원 조회: GET /users/{userId}
• 회원 수정: PATCH /users/{userId}
• 회원 삭제: DELETE /users/{userId}

 

 

HTTP 요청 파라미터로 보내는 방식은 아래 3가지 방식이 있다.

 

 

GET - 쿼리 파라미터(getParameter)

• /url?username=hello&age=20
• 메시지 바디 없이, URL의 쿼리 파라미터에 데이터를 포함해서 전달
• 예) 검색, 필터, 페이징등에서 많이 사용하는 방식

 

 

 

 

 

POST - HTML Form(getParameter)

• content-type: application/x-www-form-urlencoded
• 메시지 바디에 쿼리 파리미터 형식으로 전달 username=hello&age=20
• 예) 회원 가입, 상품 주문, HTML Form 사용

 

 

 

 

 

HTTP message body에 데이터를 직접 담아서 요청(messageConverter)

• HTTP API에서 주로 사용, JSON, XML, TEXT
• 데이터 형식은 주로 JSON 사용
• POST, PUT, PATCH

 

 

 

 

 

 

 

 

 

 

 

 

<출처 김영한: 스프링 MVC 1편 - 벡앤드 웹 개발 핵심 기술>

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1/dashboard

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의