| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
- kafka
- 지연 로딩
- redis
- @ComponentScan
- AWS
- Spring Data JPA
- Spring Container
- DLQ
- @Transactional
- docker
- 스프링 부트
- JPA
- 쿠버네티스
- Routing Key
- docker compose
- 컨테이너
- JdbcTemplate
- CORS
- dockerhub
- JPQL
- MSA
- securitycontextholderfilter
- Dead Letter Queue
- 서블릿 컨테이너
- 페이징
- Web
- mybatis
- Spring
- JWT
- DI
- Today
- Total
look-forest
HTTP 메시지 컨버터 본문
뷰 템플릿으로 HTML을 생성해 응답하는 것이 아니라,
HTTP API처럼 JSON, String 등을 body에 직접 읽거나 쓰는 경우 HTTP 메시지 컨버터가 동작한다.
HttpMessageConverter
HTTP 메시지 body에 JSON을 직접 반환하는 경우, ViewResolver 대신에 HttpMessageConverter가 동작한다.

Spring MVC는 다음의 경우에 HttpMessageConverter를 적용한다.
- HTTP 요청 : @RequestBody, HttpEntity (RequestEntity)
- HTTP 응답 : @ResponseBody, HttpEntity (ResponseEntity)
HttpMessageConverter 인터페이스
package org.springframework.http.converter;
public interface HttpMessageConverter<T> {
//특정 메시지 컨버터가 해당 클래스, 미디어타입을 지원하는지 체크.
boolean canRead(Class<?> clazz, @Nullable MediaType mediaType);
boolean canWrite(Class<?> clazz, @Nullable MediaType mediaType);
List<MediaType> getSupportedMediaTypes();
//메세지컨버터는 읽기와 쓰기에 모두 사용된다.
T read(Class<? extends T> clazz, HttpInputMessage inputMessage);
void write(T t, @Nullable MediaType contentType, HttpOutputMessage outputMessage);
}
HttpMessageConverter는 인터페이스로, 스프링은 다양한 구현체를 자동 등록해준다.
대상 클래스 타입과 미디어 타입을 체크해서 특정 구현체 사용 여부를 결정한다.
- ByteArrayHttpMessageConverter
- StringHttpMessageConverter
- MappingJackson2HttpMessageConverter
조건을 만족하지 않으면 다음 메시지 컨버터로 우선순위가 넘어간다.
- ByteArrayHttpMessageConverter : 클래스타입 byte[] , 미디어타입 */*
- StringHttpMessageConverter : 클래스타입 String , 미디어타입 */*
- MappingJackson2HttpMessageConverter : 클래스타입 객체/HashMap , 미디어타입 application/json
* 미디어 타입 : 요청 - Content-Type / 응답 - Accept
요청 매핑 핸들러 어댑터 구조
HTTP 메시지 컨버터는 전체 Spring 구조에서 어디를 차지하는지 알아보자.
@RequestMapping 기반 컨트롤러를 사용할 때, 놀랍도록 다양한 파라미터 타입과 리턴 타입을 지원한다.
다음과 같이 컨트롤러가 호출될 때, 파라미터 값을 누가 던져서 호출해줄까?

어댑터가 컨트롤러를 호출한다.
@RequestMapping을 처리하는 핸들러 어댑터인 RequestMappingHandlerAdapter가 파라미터를 넣어주는 것이다.

어댑터는 Argument Resolver와 ReturnValueHandler의 지원으로 이를 가능케 한다.
HandlerMethodArgumentResolver
- RequestMappingHandlerAdapter는 ArgumentResolver를 호출해 핸들러 메소드가 필요로 하는 파라미터 값(객체) 생성
- 파라미터 값이 모두 준비되면 컨트롤러를 호출하면서 값을 넘겨준다.

동작 방식
- ArgumentResolver 의 supportsParameter() 를 호출해서 해당 파라미터를 지원하는지 체크
- 지원하면 resolveArgument() 를 호출해서 실제 객체를 생성
- 생성된 객체가 컨트롤러 호출시 전달
직접 이 인터페이스를 확장해서 원하는 ArgumentResolver 를 만들 수도 있다. 향후 로그인 처리에서 활용
ReturnValueHandler
- ArgumentResolver 와 비슷한데, 이것은 응답 값을 변환하고 처리한다
- 컨트롤러에서 String으로 뷰 이름을 반환해도, 동작하는 이유가 바로 ReturnValueHandler 덕분이다.
HTTP 메시지 컨버터
ArgumentResolver와 ReturnValueHandler에서 HTTP 메시지 body에 직접 읽고, 쓰기가 필요한 경우
HTTP 메시지 컨버터를 사용해서 필요한 객체를 생성한다.
- 요청 : @RequestBody 를 처리하는 ArgumentResolver 가 있고, HttpEntity 를 처리하는 ArgumentResolver 가 있다
- 응답 : @ResponseBody 와 HttpEntity 를 처리하는 ReturnValueHandler 가 있다

기능 확장은 WebMvcConfigurer 를 상속 받아서 스프링 빈으로 등록하면 된다
참고 자료 & 이미지 출처
스프링 MVC 1편(김영한 님)
'Spring > Spring MVC - 웹 개발 핵심 기술' 카테고리의 다른 글
| 요약 (0) | 2024.08.22 |
|---|---|
| Redirect 관련 (0) | 2023.08.26 |
| 스프링 MVC 기본 기능 - 응답 (0) | 2023.08.22 |
| 스프링 MVC 기본 기능 - 요청 (0) | 2023.05.07 |
| Spring MVC 구조 이해 (0) | 2023.05.01 |