Notice
Recent Posts
Recent Comments
Link
«   2025/01   »
일 월 화 수 목 금 토
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 31
Tags more
Archives
Today
Total
관리 메뉴

나구리의 개발공부기록

스프링 MVC - 기본기능, 응답(정적리소스 / 뷰 템플릿), HTTP 응답(HTTP API / 메시지바디에 직접 입력), HTTP 메시지 컨버터, 요청 매핑 핸들러 어댑터 구조 본문

인프런 - 스프링 완전정복 코스 로드맵/스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

스프링 MVC - 기본기능, 응답(정적리소스 / 뷰 템플릿), HTTP 응답(HTTP API / 메시지바디에 직접 입력), HTTP 메시지 컨버터, 요청 매핑 핸들러 어댑터 구조

소소한나구리 2024. 3. 4. 15:29

  출처 : 인프런 - 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 (유료) / 김영한님  
  유료 강의이므로 정리에 초점을 두고 코드는 일부만 인용  

https://inf.run/Gmptq

1. HTTP응답 - 정적리소스, 뷰 템플릿

1) HTTP 응답

(1) 스프링(서버)에서 응답 데이터를 만드는 3가지 방법

  • 정적 리소스 : 예) 웹 브라우저에 정적인 HTML, css, js를 제공할 때
  • 뷰 템플릿 사용 : 예) 웹 브라우저에 동적인 HTML을 제공할 때
  • HTTP 메시지 사용 : HTTP API를 제공하는 경우 데이터를 전달해야 하므로 HTTP 메시지 바디에 JSON과 같은 형식으로 데이터를 전송

2) 정적 리소스

(1) 정적 리소스

  • 스프링 부트는 클래스패스의 다음디렉토리에 있는 정적 리소스를 제공함
  • /static, /public, /resources, /META-INF/resources
  • src/main/resources는 리소스를 보관하는곳이자 클래스패스의 시작 경로이므로 다음 디렉토리에 리소스를 넣어두면 스프링 부트가 정적 리소스로 서비스를 제공
  • 정적 리소스는 해당 파일을 변경 없이 그대로 서비스 하는 것임

(3) 정적 리소스 경로

  • src/main/resources/static 경로에 hello-form.html파일이 들어있으면?
  • http://localhost:8080/basic/hello-form.html로 접속하면 페이지가 뜸

3) 뷰 템플릿

(1) 뷰 템플릿

  • 뷰 템플릿을 거쳐서 HTML이 생성되고 뷰가 응답을 만들어서 전달
  • 일반적으로 동적 HTML을 생성하는 용도로 사용하지만 다른 것들도 가능함(뷰 템플릿이 만들 수 있는 것이라면 무엇이든 가능)

(2) 뷰 템플릿 경로

  • src/main/resources/templates

(3) 뷰 템플릿 생성 - hello.html

  • src/main/resources/templates/response경로에 생성
<!DOCTYPE html>
<!--타임리프를 사용-->
<html xmlns:th="http://www.thymeleaf.org">

<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<!--model에 ${data}의 내용이 empty에 치환되어 렌더링-->
<p th:text="${data}">empty</p>
</body>
</html>

 

(4-1) ResponseViewController - responseViewV1

  • basic하위에 response패키지를 생성 후 작성
  • ModelAndView를 반환하는 뷰 템플릿 호출 컨트롤러 
package hello.springmvc.basic.response;

@Controller
public class ResponseViewController {

    @RequestMapping("/response-view-v1")
    public ModelAndView responseViewV1() {
        ModelAndView mav = new ModelAndView("response/hello").addObject("data", "hello!");
        return mav;
    }
}

 

(4-2) ResponseViewController - responseViewV2

  • String을 반환하는 뷰 템플릿 호출 컨트롤러
  • @ResponseBody가 없으면 반환값("response/hello")로 뷰 리졸버가 실행 되어서 뷰를 찾고 렌더링 함
  • @ResponseBody가 있으면 뷰 리졸버가 실행하지 않고 response/hello 라는 문자가 입력 됨(HTTP 바디에 직접 입력)
@RequestMapping("/response-view-v2")
public String responseViewV2(Model model) {
    model.addAttribute("data", "hello!");
    return "response/hello";
}

 

(4-3) ResponseViewController - responseViewV3

  • 반환타입을 생략할 수 있으나 권장하지 않는 방법
  • @Controller를 사용하고 HttpServletResponse, OutputStream(Writer)와 같은 HTTP 메시지 바디를 처리하는 파라미터가 없으면 URL을 참고해서 논리 뷰 이름으로 사용함
  • 하지만 명시성이 너무 떨어지고 이렇게 상황이 딱 맞는 경우가 많이 없어서 권장하지 않음
// 권장하지 않는 방법 - 컨트롤러의 이름과 뷰의 논리적이름이 같으면 반환타입(반환)을 생략할 수 있음
@RequestMapping("/response/hello")
public void responseViewV3(Model model) {
    model.addAttribute("data", "hello!");
}

 

(5) HTTP 메시지

  • @ResponseBody, HttpEntity를 사용하면 뷰 템플릿을 사용하는 것이 아니라 HTTP 메시지 바디에 직접 응답 데이터를 출력할 수 있음

(6) Thymeleaf

  • 해당 사이트에서 thymeleaf 검색
  • build.gradle에 아래의 코드를 추가하면 스프링 부트가 자동으로 ThymeleafViewResolver와 필요한 스프링 빈들을 등록하고 기본 설정들을 사용함
  • 프로젝트 생성 시 타임리프 라이브러리를 선택하면 알아서 입력되어있음
implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'

// Thymeleaf 기본설정 -> 기본값이기 때문에 application.properties에서 값을 변경할 수 있지만 바꿀일이 없음
spring.thymeleaf.prefix=classpath:/templates/
spring.thymeleaf.suffix=.html

2. HTTP응답 - HTTP API, 메시지 바디에 직접 입력

1) HTTP API

(1) 메시지 바디에 직접 입력

  • HTTP API를 제공하는 경우 HTML이 아니라 데이터를 전달해야 하므로 HTTP 메시지 바디에 JSON 같은 형식으로 데이터를 전송함
  • HTTP 요청강의에서 응답까지 대부분 다루었으므로 정리에 초점을 맞춤

** 참고

  • 참고로 HTML이나 뷰 템플릿을 사용해도 HTTP 응답 메시지 바디에 HTML 데이터가 담겨서 전달 됨
  • 여기에서 설명하는 내용은 정적 리소스나 뷰 템플릿을 거치지 않고 직접 HTTP 바디에 응답 메세지를 전달하는 경우임

(2) ResponseBodyController - responseBodyV1

  • 가장 단순한 문자열 처리 방법
  • 서블릿을 다룰 때처럼 HttpServletResponse객체를 통해서 HTTP 메시지 바디에 직접 응답 메시지를 전달
package hello.springmvc.basic.response;

@Slf4j
@Controller
public class ResponseBodyController {

    @GetMapping("/response-body-string-v1")
    public void responseBodyV1(HttpServletResponse response) throws IOException {
        response.getWriter().write("ok");
    }
}

 

(3) ResponseBodyController - responseBodyV2

  • ResponseEntity<String>로 문자열 처리
  • ResponseEntity는 HttpEntity(HTTP 메시지 헤더, 바디의 정보를 가지고 있음)를 상속받음
  • ResponseEntity는 여기에 더해 HTTP 응답 코드를 설정할 수 있음
@GetMapping("/response-body-string-v2")
public ResponseEntity<String> responseBodyV2() {
    return new ResponseEntity<>("ok", HttpStatus.OK);
//    return ResponseEntity.ok("ok");   // 위와 동일
}

 

(4) ResponseBodyController - responseBodyV3

  • @ResponseBody로 문자열 처리 
  • @ResponseBody를 사용하면 view를 사용하지 않고 HTTP 메시지 컨버터를 통해 HTTP 메시지를 직접 입력 가능
    (ResponseEntity도 동일한 방식으로 작동)
@ResponseBody
@GetMapping("/response-body-string-v3")
public String responseBodyV3() {
    return "ok";
}

 

(5) ResponseBodyController - responseBodyJsonV1

  • ResponseEntity로 Json 처리 
  • ResponseEntity를 반환 -> HTTP 메세지 컨버터를 통해 JSON 형식으로 변환되어서 반환
@GetMapping("/response-body-json-v1")
public ResponseEntity<HelloData> responseBodyJsonV1() {
    HelloData helloData = new HelloData();
    helloData.setUsername("UserA");
    helloData.setAge(20);
    return new ResponseEntity<>(helloData, HttpStatus.OK);
//    return ResponseEntity.ok(helloData); // 위와 동일
}

 

(6) ResponseBodyController - responseBodyJsonV2

  • @ResponseBody, @ResponseStatus를 사용한 Json 처리
  • @ResponseBody는 응답코드 설정하기가 까다로운데 이를 @ResponseStatus를 활용하여 응답코드를 반환할 수 있음
  • 애노테이션이기 때문에 응답코드를 동적으로 변경할 수 없어서 프로그램 조건에 따라 동적으로 변경하려면 ResponseEntity를 사용
// 상황에 따라 상태코드를 반환(동적으로 반환)하지 못함, 동적으로 적용할 때는 버전 사용
@ResponseStatus(HttpStatus.OK)
@ResponseBody
@GetMapping("/response-body-json-v2")
public HelloData responseBodyJsonV2() {
    HelloData helloData = new HelloData();
    helloData.setUsername("UserA");
    helloData.setAge(20);
    return helloData;
}

 

(7) ResponseBodyController - @RestController(개발시 가장 많이 사용)

  • 클래스레벨에 @ResponseBody 애노테이션을 적용하면 전체 메서드에 적용이 되어 메서드 레벨에서 코드중복을 제거할 수 있음
  • @Controller대신에 @RestController를 사용하면 클래스레벨에서의 @ResponseBody와 @Controller가 적용되는 효과를 볼 수 있음
  • 뷰 템플릿을 사용하는 것이 아닌 HTTP 바디에 직접 데이터를 입력함
  • RestController는 이름 그대로 REST API(HTTP API)를 만들때 사용하는 컨트롤러임
@Slf4j
// @Controller
// @ResponseBody // -> 클래스레벨에 적용하면 메서드 레벨에 작성된 @ResponseBody 생략 가능
@RestController // -> @ResponsBody와 @Controller가 다 붙어있음 -> 매우 편리해짐(가장 많이씀)
public class ResponseBodyController {
    // 기타 코드 유지
}

3. HTTP 메시지 컨버터

1) 설명

(1) @ResponseBody 사용원리(스프링 입문 강의 내용)

  1. HTTP BODY에 문자 내용을 직접 반환
  2. viewResolver대신 HttpMessageConverter가 동작
  3. 기본 문자처리: StringHttpMessageConverter
  4. 기본 객체처리: MappingJackson2HttpMessageConverter
  5. byte 처리 등등 여러 HttpMessageConverter가 기본으로 등록 되어 있음

 

(2) 스프링 MVC의 HTTP 메시지 컨버터 적용 상황

  • HTTP 요청: @RequestBody, HttpEntity(RequestEntity)
  • HTTP 응답: @ResponseBody, HttpEntity(ResponseEntity)

(3) HTTP 메시지 컨버터 인터페이스

  • HTTP 메시지 컨버터는 HTTP요청, HTTP응답 둘다 사용됨
  • canRead(), canWrite() : 메시지 컨버터가 해당 클래스와 미디어타입을 지원하는지 체크
  • read(), write() : 메시지 컨버터를 통해 메시지를 읽고 쓰는 기능
public interface HttpMessageConverter<T> {

    boolean canRead(Class<?> clazz, @Nullable MediaType mediaType);
    boolean canWrite(Class<?> clazz, @Nullable MediaType mediaType);

    List<MediaType> getSupportedMediaTypes();

    default List<MediaType> getSupportedMediaTypes(Class<?> clazz) {
       return (canRead(clazz, null) || canWrite(clazz, null) ?
             getSupportedMediaTypes() : Collections.emptyList());
    }

    T read(Class<? extends T> clazz, HttpInputMessage inputMessage)
          throws IOException, HttpMessageNotReadableException;

    void write(T t, @Nullable MediaType contentType, HttpOutputMessage outputMessage)
          throws IOException, HttpMessageNotWritableException;

}

 

(4-1) 스프링부트의 기본 메시지 컨버터(일부 생략)

  • 대상 클래스타입과 미디어 타입을 체크해서 사용여부를 결정하고 만족하지 않으면 다음 컨버터로 우선권이 넘어감
  • ByteArrayHttpMessageConverter: byte[] 데이터를 처리, 클래스 타입 - byte[], 미디어타입 - */*
  • StringHttpMessageConverter: String 문자로 데이터를 처리, 클래스 타입 - String, 미디어타입 - */*
  • MappingJackson2HttpMessageConverter: application/json 처리, 클래스 타입 - 객체 or HashMap, 미디어타입 - application/json관련
// Byte[] 데이터 처리
// 클래스타입 : byte[], 미디어타입 : */*(모두 가능)
0 = ByteArrayHttpMessageConverter

// 문자로 데이터 처리
// 클래스 타입 : String, 미디어타입 : */*
1 = StringHttpMessageConverter

// application/json 처리
// 클래스 타입 : 객체 또는 HashMap, 미디어 타입 : application/json
2 = MappingJackson2HttpMessageConverter

 ...

 

(4-2) StringHttpMessageConvertor 동작 예시

  • 클래스 타입 - String, 미디어타입 - 모두 가능
// content-type: application/json

@RequestMapping
void hello(@RequestBody String data) {}

 

(4-3) StringHttpMessageConvertor 동작 예시

  • 클래스 타입 - 객체, 미디어 타입 - application/json
// content-type: application/json

@RequestMapping
void hello(@RequestBody HelloData data) {}

 

(4-4) 오류 예시

  • 탈락: 클래스 타입이 객체이고 미디어 타입이 text/html을 지원하는 컨버터를 찾을 수 없음
// content-type: text/html

@RequestMapping
void hello(@RequestBody HelloData data) {}

 

(5) HTTP 요청 데이터 읽기

  • HTTP 요청이 오고 컨트롤러에서 @ResponseBody, HttpEntity 파라미터를 사용함
  • 메시지 컨버터가 메시지를 읽을 수 있는지 확인하기 위해 canRead()를 호출 (클래스타입 지원, 미디어 타입 지원 여부 확인)
  • canRead()조건을 만족하면 read()를 호출해서 객체를 생성하고 반환

(6) HTTP 응답 데이터 생성

  • 컨트롤러에서 @ResponseBody, HttpEntity로 값이 반환됨
  • 메시지 컨버터가 메시지를 쓸 수 있는지 확인하기 위해 canWrite()호출 (클래스타입 지원, HTTP Accept미디어 타입 지원 여부 확인,더 정확히는 @RequestMapping의 produces값 확인)
  • canWrite()조건을 만족하면 write()를 호출해서 HTTP 메시지 바디에 데이터를 생성

4. 요청 매핑 핸들러 어댑터 구조 

(1) HTTP 메시지 컨버터가 스프링 MVC 어디쯤에서 사용 될까?

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

(2) RequestMappingHandlerAdapter 동작방식 / HTTP 메세지 컨버터 위치 그림

좌) RequestMappingHandlerAdapter 동작 방식 / 우) HTTP 메세지 컨버터 위치

 

(3-1) ArgumentResolver (HandlerMethodArgumentResolver)

  • 애노테이션 기반의 컨트롤러가 매우 다양한 파라미터를 사용할 수 있는 이유(HttpServletRequest, Model, @RequestParam, @ModelAttribute, @RequestBody, HttpEntity)는 ArgumentResolver덕분임
  • 애노테이션 기반 컨트롤러를 처리하는 RequestMappingHandlerAdapter는 ArgumentResolver를 호출해서 컨트롤러(핸들러)가 필요로 하는 다양한 파라미터의 값(객체)을 생성하고 파라미터의 값이 모두 준비 되면 컨트롤러를 호출하면서 값을 넘겨 줌
  • 스프링은 30개가 넘는 ArgumentResolver를 기본으로 제공함
  • 공식 메뉴얼

(3-2) ArgumentResolver 동작 방식

  • ArgumentResolver의 supportsParameter()를 호출해서 해당 파라미터를 지원하는지 체크하고 지원하면 resolverArgument()를 호출해서 실제 객체를 생성함
  • 그리고 생성된 객체가 컨트롤러 호출시 넘어감
  • 인터페이스이기 때문에 원하는 ArgumentResolver를 만들 수 있음(MVC2편의 로그인 처리에서 예제가 나옴)
public interface HandlerMethodArgumentResolver {
    boolean supportsParameter(MethodParameter parameter);
    
    @Nullable
    Object resolveArgument(MethodParameter parameter,
                           @Nullable ModelAndViewContainer mavContainer,
                           NativeWebRequest webRequest,
                           @Nullable WebDataBinderFactory binderFactory) throws Exception;
}

 

(4) ReturnValueHandler (HandlerMethodReturnValueHandler)

  • ArgumentResolver와 비슷하며 응답 값을 변환하고 처리함
  • 컨트롤러에서 String으로 뷰 이름을 반환해도 동작하는 이유가 ReturnValueHandler덕분임
  • 스프링은 10개가 넘는 ReturnValueHandler를 지원함
  • 예) ModelAndView, @ResponseBody, HttpEntity, String
  • 공식메뉴얼

(5) HTTP 메시지 컨버터

  • HTTP 메시지 컨버터를 사용하는 @RequestBody도 컨트롤러가 필요로하는 파라미터의 값에 사용되며 @ResponseBody의 경우도 컨트롤러의 반환 값을 이용함
  • 요청: @RequestBody와 HttpEntity를 처리하는 ArgumentResolver들이 HTTP 메시지 컨버터를 사용해서 객체를 생성
  • 응답: @ResponseBody와 HttpEntity를 처리하는 ReturnValueHandler가 HTTP 메시지 컨버터를 사용해서 응답함
  • @RequestBody, @ResponseBody가 있으면 RequestResponseBodyMethodProcessor를, HttpEntity가 있으면 HttpEntityMethodProcessor를 사용

(6-1) 확장

  • 스프링은 HandlerMethodArgumentResolver, HandlerMethodReturnValueHandler, HttpMessageConverter를 모두 인터페이스로 제공하기 때문에 언제든지 기능을 확장할 수 있음
  • 스프링이 필요한 대부분의 기능을 제공하기 때문에 확장할 일이 거의 없지만 만약 확장이 필요하다면 WebMvcConfigurer를 상속받아서 스프링 빈으로 등록하면 됨
  • 자주 사용하지는 않으니 필요할 때 WebMvcConfigurer를 검색하여 참고

(6-2) WebMvcConfigurer 확장 예시

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

 

'인프런 - 스프링 완전정복 코스 로드맵 > 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술' 카테고리의 다른 글

스프링 MVC - 웹 페이지 만들기, 상품 상세, 상품 등록 폼, 상품 등록 처리 - @ModelAttribute, 상품수정, PRG Post/Redirect/Get, RedirectAttributes  (0) 2024.03.09
스프링 MVC - 웹페이지 만들기, 프로젝트 생성 및 요구사항 분석, 요구사항 분석, 상품 도메인 개발, 상품 서비스 HTML, 상품 목록 - 타임리프  (1) 2024.03.04
스프링 MVC - 기본기능, HTTP요청 (기본/헤더 조회), HTTP 요청 파라미터(쿼리파라미터/HTML Form/@RequestParam/@ModelAttribute), HTTP 요청메시지(단순텍스트/JSON)  (0) 2024.03.03
스프링 MVC - 기본기능, 프로젝트 생성, 로깅(간단히알아보기), 요청매핑, 요청매핑 - API 예시  (0) 2024.03.01
스프링 MVC - 구조이해, 스프링 MVC (시작하기/컨트롤러 통합하기/실용적인 방식)  (0) 2024.02.29
'인프런 - 스프링 완전정복 코스 로드맵/스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술' Related Articles more