[Spring] #6. 스프링 MVC - 기본기능 (김영한_인프런_스프링MVC1)

bien·2023년 4월 22일

springMVC

Spring_MVC1

목록 보기

7/8

프로젝트 생성

http://start.spring.io

프로젝트 선택

Project: Gradle Project
Language: Java
Spring Boot: 2.7.10 (이후 2.7.9로 변경)

Project Metadata

Group: hello
Artifact: springmvc
Name: springmvc
Package name: hello.springmvcPackaging: Jar (주의!)
Java: 11

Dependencies: Spring Web, Thymeleaf, Lombok

주의!
Packaging는 War가 아니라 Jar를 선택한다. 톰캣과 같은 was서버를 별도로 설치하고 거기에 빌드된 파일을 넣을 때, 또는 JSP를 쓸 때 WAR를 사용한다. 그 외 내장톰캣에 최적화해서 바로 사용하고 싶을때는 JAR를 사용한다. Jar를 사용하면 항상 내장 서버(톰캣등)를 사용하고. webapp경로도 사용하지 않는다. 내장 서버 사용에 최적화되어 있는 기능이므로 주로 이방식을 사용한다. War를 사용하면 내장 서버도 사용 가능하지만, 주로 외부 서버에 배포한는 목적으로 사용한다.

동작확인
기본메인클래스 실행( SpringmvcApplication.main() )
http://localhost:8080 호출해서 Whitelabel Error Page가나오면 정상동작

Welcome 페이지 만들기

스프링 부트에 Jar를 사용하면 /resources/static위치에 index.html파일을 두면 Welcome 페이지로 처리해준다.(스트링 부트가 지원하는 정적 컨텐츠 위에 `/index.html이 있으면 된다.

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<ul>
    <li>로그 출력
        <ul>
            <li><a href="/log-test">로그 테스트</a></li>
        </ul>
    </li>
    <!-- -->
    <li>요청 매핑
        <ul>
            <li><a href="/hello-basic">hello-basic</a></li><li><a href="/mapping-get-v1">HTTP 메서드 매핑</a></li>
            <li><a href="/mapping-get-v2">HTTP 메서드 매핑 축약</a></li>
            <li><a href="/mapping/userA">경로 변수</a></li>
            <li><a href="/mapping/users/userA/orders/100">경로 변수 다중</a></li>
            <li><a href="/mapping-param?mode=debug">특정 파라미터 조건 매핑</a></li>
            <li><a href="/mapping-header">특정 헤더 조건 매핑(POST MAN 필요)</a></
            <li><a href="/mapping-consume">미디어 타입 조건 매핑 Content-Type(POST
                li>
                MAN 필요)</a></li>
            <li><a href="/mapping-produce">미디어 타입 조건 매핑 Accept(POST MAN
                필요)</a></li>
        </ul>
    </li>
    <li>요청 매핑 - API 예시
        <ul>
            <li>POST MAN 필요</li>
        </ul>
    </li>
    <li>HTTP 요청 기본
        <ul>
            <li><a href="/headers">기본, 헤더 조회</a></li>
        </ul>
    </li>
    <li>HTTP 요청 파라미터
        <ul>
            <li><a href="/request-param-v1?username=hello&age=20">요청 파라미터
                v1</a></li>
            <li><a href="/request-param-v2?username=hello&age=20">요청 파라미터
                v2</a></li>
            <li><a href="/request-param-v3?username=hello&age=20">요청 파라미터
                v3</a></li>
            <li><a href="/request-param-v4?username=hello&age=20">요청 파라미터
                v4</a></li>
            <li><a href<li><a href="/model-attribute-v1?username=hello&age=20">요청 파라미터
            @ModelAttribute v1</a></li>
            <li><a href="/model-attribute-v2?username=hello&age=20">요청 파라미터
                @ModelAttribute v2</a></li>
        </ul>
    </li>
    <li>HTTP 요청 메시지
        <ul>
            <li>POST MAN</li>
        </ul>
    </li>
    <li>HTTP 응답 - 정적 리소스, 뷰 템플릿
        <ul>
            <li><a href="/basic/hello-form.html">정적 리소스</a></li>
            <li><a href="/response-view-v1">뷰 템플릿 v1</a></li>
            <li><a href="/response-view-v2">뷰 템플릿 v2</a></li>
        </ul>
    </li>
    <li>HTTP 응답 - HTTP API, 메시지 바디에 직접 입력
        <ul>
            <li><a href="/response-body-string-v1">HTTP API String v1</a></li>
            <li><a href="/response-body-string-v2">HTTP API String v2</a></li>
            <li><a href="/response-body-string-v3">HTTP API String v3</a></li>
            <li><a href="/response-body-json-v1">HTTP API Json v1</a></li>
            <li><a href="/response-body-json-v2">HTTP API Json v2</a></li>
        </ul>
    </li>
</ul>
</body>
</html>

로깅 간단히 알아보기

앞으로 로그를 사용할 것이기 때문에, 이번 시간에는 로그에 대해서 간단히 알아보자.

운영시스템에서는 System.out.println() 같은 시스템 콘솔을 사용해서 필요한 정보를 출력하지 않고, 별도의 로깅 라이브러리를 사용해서 로그를 출력한다. 참고로 로그 관련 라이브러리도 많고, 깊게 들어가면 끝이 없기 때문에, 여기서는 최소한의 사용 방법만 알아본다.

로깅 라이브러리

스프링 부트 라이브러리를 사용하면 스프링 부트 로깅 라이브러리(spring-boot-starter-logging)가 함께 포함된다. 스프링 부트 로깅 라이브러리는 기본으로 다음 로깅 라이브러리를 사용한다.

SLF4J: http://www.slf4j.org
Logback: http://logback.qos.ch
로그 라이브러리는 Logback, Log4J, Log4J2 등등 수많은 라이브러리가 있는데, 그것들을 통합해서 인터페이스화 한 프로젝트가 바로 SFL4J 라이브러리다. 어떤 로그프로젝트더라도 내가 인터페이스화 해주고 어뎁터같은거 다 구현해서 쓸 수 있게 라이브러리 이름만 바꾸면 바꿀 수 있게 해주겠다, 하고 나온게 SLF4J! 그 구현체 중 하나가 Logback. 실무에서는 스프링 부트가 기본으로 제공하는 Logback을 대부분 사용한다.

로그 선언

3가지 방법 모두 사용 가능.
private Logger log = LoggerFactory.getLogger(getClass());
private static final Logger log = LoggerFactory.getLogger(Xxx.class)
@Slf4j : 롬복사용가능 (애노테이션만 붙여줘도 사용 가능)

로그 호출

log.info("hello")
System.out.println("hello")

LogTestController

package hello.springmvc.basic;

import lombok.extern.slf4j.Slf4j;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

//@Slf4j
@RestController
public class LogTestController {

    private final Logger log = LoggerFactory.getLogger(getClass());

    @RequestMapping("/log-test")
    public String logTest() {
        String name = "Spring";

        System.out.println("name = " + name);

        log.trace("trace log={}", name);
        log.debug("debug log={}", name);
        log.info("info log={}", name);
        log.warn("warn log={}", name);
        log.error("error log={}", name);

        // 로그를 사용하지 않아도 a+b 계산 로직이 먼저 실행됨, 이런 방식으로 사용하면 x
        log.debug("String concat log = " + name);
        return "ok";
    }
}

실행

http://localhost:8080/log-test

매핑 정보

@RestController

@Controller는 반환값이 String이면 뷰 이름으로 인식한다. 그래서 뷰를 찾고 뷰가 렌더링 된다.
@RestController는 반환값이 String이면 뷰를 찾는게 아니라, HTTP 메시지 바디에 바로 입력한다. 따라서 실행결과로 ok메시지를 받을 수 있다. @ResponseBody와 관련이 있는데, 뒤에서 더 자세히 설명한다.

테스트

시간, 로그레벨(INFO), 프로세스ID, [현재 실행한 쓰레드명], 현재나의 컨트롤러 이름,: 로그 메세지

로그레벨 설정을 변경해서 출력 결과를 보자

LEVEL: TRACE > DEBUG > INFO > WARN > ERROR
개발 서버는 debug 출력
운영 서버는 info 출력

로그 레벨 설정

로그를 찍을 때 레벨을 정할 수 있음.

ex)
debug: 현재로그는 디버그할 때, 개발 서버에서 보는 거야
info: 현재 로그는 중요한 비즈니스 정보야. 운영시스템에서도 봐야 할 정보야
warn: 이거는 위험한거야.
error: 이거는 에러야. 우리가 빨리 확인해야해. error가 뜨면 알람을 보거나 별도로 어디 파일에 남겨서 보거나 등등 할 수 있다.

application.properties

#전체 로그 레벨 설정(기본 info) 
logging.level.root=info

#hello.springmvc 패키지와 그 하위 로그 레벨 설정 
logging.level.hello.springmvc=debug

로그 레벨에 맞춰 출력되는 로그를 조절 -> 중요한 정보만 선택적으로 출력 가능. 트래픽이 많아 출력되는 로그가 과도하게 많을 때, 필요한 정보만 선택적으로 출력해 볼 수 있다는 장점!
기본셋팅: info부터 출력
(if. 이걸 debug로 바꾸면.. 모든 라이브러리에 다 log가 있음. 스프링부트가 어마어마한 정보들을 출력하게 됨. 기본은 info로 두고 원하는 부분만 살짝식 바꾸는게 좋다.)

올바른 로그 사용법

log.debug("data="+data)

로그 출력 레벨을 info로 설정해도 해당 코드에 있는 “data="+data가 실제 실행이 되어 버린다. 결과적으로 문자 더하기 연산이 발생한다.
debug로그를 출력하지 않겠다 설정해서 해당 코드가 의미가 없더라도, 자바 언어의 특성에 의해 문자 더하기 연산이 발생한 이후 debug코드 여부를 확인하게 됨. 의미없는 연산으로 인해 resource를 소비해야 한다.

log.debug("data={}", data);

로그 출력 레벨을 info로 설정하면 아무일도 발생하지 않는다. 따라서 앞과 같은 의미없는 연산이 발생하지 않는다.

로그 사용 시 장점

쓰레드 정보, 클래스 이름과 같은 부가정보 함께 확인 가능, 출력 모양 조정 가능.
로그레벨에 따라 개발 서버에서는 모든 로그를 출력하고, 운영서버에서는 출력하지 않는 등 로그를 상황에 맞게 조절할 수 있다.
시스템 아웃 콘솔에만 출력하는 것이 아니라, 파일이나 네트워크 등, 로그를 별도의 위치에 남길 수 있다. 특히 파일로 남길 때는 일별 ,특정 용량에 따라 로그를 분할하는 것도 가능하다.
sysout은 그냥 콘솔에남음. 로그는 뒤에 설정해주면 파일로 별도로 남길 수 있음. 더 많이 하면 네트워크로 로그를 전송할 수도 있음. 뿐만 아니라 로그 사용 시 파일로 남길 때 (100메가가 넘으면 파일을 분리해, 파일을 10개만 유지해, 압축해서 백업해) 이런 것들도 다 자동화 가능하도록 설정 가능.
성능도 일반 System.out보다 좋다.(내부 버퍼링, 멀티 쓰레드 등등) 그래서 실무에서는 꼭 로그를 사용해야 한다!
애플리케이션 코드를 손대지 않고, 설정 만으로 출력할 로그의 범위를 조절 가능하다는 것도 장점!

더 공부하실 분

로그에대해서 더 자세한내용은 slf4j, logback을검색해보자.

SLF4J: http://www.slf4j.org
Logback: http://logback.qos.ch
스프링부트가 제공하는 로그 기능은 다음을 참고하자.
https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-
features.html#boot-features-logging

요청 매핑

요청매핑 : 요청이 왔을 때 어떤 컨트롤러가 호출되어야 하는지 매핑 하는 것 (단순하게 url을 통해 매핑하는 방법 뿐만 아니라, 여러 요소를 조합해서 매핑한다.)

MappingController

  package hello.springmvc.basic.requestmapping;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.*;

@RestController
public class MappingController {

    private Logger log = LoggerFactory.getLogger(getClass());

    /**
     * 기본 요청
     * 둘다 허용 /hello-basic, /hello-basic/
     * HTTP 메서드 모두 허용 GET, HEAD, POST, PUT, PATCH, DELETE
     */
    @RequestMapping("/hello-basic")
    public String helloBasic() {
        log.info("helloBasic");
        return "ok";
    }
  }

매핑 정보(한번 더)

@RestController

@Controller는 반환값이 String이면 뷰 이름으로 인식된다. 그래서 뷰를 찾고 뷰가 랜더링된다.
@RestController는 반환값으로 뷰를 찾는 것이 아니라, HTTP 메시지 바디에 바로 입력한다. 따라서 실행 결과로 ok메시지를 받을 수 있다. @ResponseBody와 관련이 있는데, 뒤에서 더 자세히 설명한다.
(@RestController로 오류의 모양을 json 스타일로 보내준다.)

@RequestMapping("/hello-basic")

/hello-basic URL 호출이 오면 이 메서드가 실행되도록 매핑한다.
대부분의 속성을 배열[]로 제공하므로 다중 설정이 가능하다. {“/hello-baskc", "/hello-go"}

둘 다 허용 - 스프링 부트 3.0 이전
다음 두가지 요청은 다른 URL이지만, 스프링은 다음 URL 요청들을 같은 요청으로 매핑한다.

매핑: /hello-basic

URL 요청: /hello-basic , /hello-basic/

스프링부트 3.0 이후
스프링부트 3.0 부터는 /hello-basic, /hello-basic/는 서로 다른 URL 요청을 사용해야 한다. 기존에는 마지막에 있는 /(slash)를 제거했지만, 스프링부트 3.0 부터는 마지막의 /(slash)를 유지한다. 따라서 다음과 같이 다르게 매핑해서 사용해야 한다.

매핑: /hello-basic => URL 요청: /hello-basic

매핑: /hello-basic/ => URL 요청: /hello-basic/

HTTP 메서드

@RequestMapping에 method속성으로 HTTP 메서드를 지정하지 않으면 HTTP 메서드와 무관하게 호출된다. 모두 허용 GET, HEAD, POST, PUT, PATCH, DELETE

HTTP 메서드 매핑

   /**
     * method 특정 HTTP 메서드 요청만 허용 * GET, HEAD, POST, PUT, PATCH, DELETE
     */
    @RequestMapping(value = "/mapping-get-v1", method = RequestMethod.GET)
    public String mappingGetV1() {
        log.info("mappingGetV1");
        return "ok";
    }

만약 여기에 POST 요청을 하면 스프링 MVC는 HTTP 405상태코드(Method Not Allowed)를 반환한다.

HTTP 메서드 매핑 축약

   /**
     * 편리한 축약 애노테이션 (코드보기)
     * @GetMapping
     * @PostMapping
     * @PutMapping
     * @DeleteMapping
     * @PatchMapping
     */
    @GetMapping(value = "/mapping-get-v2")
    public String mappingGetV2() {
        log.info("mapping-get-v2");
        return "ok";
    }

HTTP 메서드를 축약한 애노테이션을 사용하는 것이 더 직관적이다. 코드를 보면 내부에서 @RequestMapping과 method를 지정해서 사용하는 것을 확인할 수 있다.

PathVariable(경로 변수) 사용

요즘엔 이런 경로 스타일을 사용 많이들 한다!

   /**
     * PathVariable 사용
     * 변수명이 같으면 생략 가능
     * @PathVariable("userId") String userId -> @PathVariable userId
     * /mapping/userA (URL자체에 값이 들어있는 것.)
     */
    @GetMapping("/mapping/{userId}")
    public String mappingPath(@PathVariable("userId") String data) {
        log.info("mappingPath userId={}", data);
        return "ok";
    }

최근 HTTP API는 다음과 같이 리소스 경로에 식별자를 넣는 스타일을 선호한다.

/mapping/userA
/users/1

@RequestMapping은 URL 경로를 템플릿화 할 수 있는데, @PathVariable를 사용하면 매칭 되는 부분을 편리하게 조회할 수 있다.

템플릿화: 임의의 값이 들어오도록 설정하는 것. 여기서는 {userId}부분

@PathVariable의 이름과 파라미터 이름이 같으면 생략할 수 있다.
변수명을 통일하면 불러오는 컬럼명을 지우고 사용할 수 있다.

    @GetMapping("/mapping/{userId}")
    public String mappingPath(@PathVariable String userId) {
        log.info("mappingPath userId={}", userId);
        return "ok";
    }

cf. 쿼리 파라미터 형식:maping?userId=userA
경로 변수 형식: /mapping/userA

PathVariable 사용 - 다중

    /**
     * PathVariable 사용 다중
     */
    @GetMapping("/mapping/users/{userId}/orders/{orderId}")
    public String mappingPath(@PathVariable String userId, @PathVariable Long orderId) {
        log.info("mappingPath userId={}, orderId={}", userId, orderId);
        return "ok";
    }

실행
http://localhost:8080/mapping/users/userA/orders/100
users=userA, orders=100

특정 파라미터 조건 매핑

    /**
     * 파라미터로 추가 매핑
     * params="mode",
     * params="!mode"
     * params="mode=debug"
     * params="mode!=debug"
     * params={"mode=debug","data=good"}
     */
    @GetMapping(value="/mapping-param", params = "mode=debug")
    public String mappingParam() {
        log.info("mappingParam");
        return "ok";
    }

잘 사용하지는 않는다. 특정 파라미터가 있거나 없는 조건을 추가할 수 있다.
(특정 파라미터가 같이 넘어와야지만 해당 매핑이 실행됨.)

실행
http://localhost:8080/mapping-param?mode=debug

특정 헤더 조건 매핑

    /**
     * 특정 헤더로 추가 매핑
     * headers="mode",
     * headers="!mode"
     * headers="mode=debug"
     * headers="mode!=debug"
     */
    @GetMapping(value="/mapping-header", headers="mode=debug")
    public String mappingHeader() {
        log.info("mappingHeader");
        return "ok";
    }

파라미터 매핑과 비슷하지만, HTTP 헤더를 사용한다.

미디어 타입 조건 매핑 - HTTP 요청 Content-Type, consume

/**
 * Content-Type 헤더 기반 추가 매핑 Media Type 
 * consumes="application/json"
 * consumes="!application/json" 
 * consumes="application/*"
 * consumes="*\/*"
 * MediaType.APPLICATION_JSON_VALUE 
 */
@PostMapping(value = "/mapping-consume", consumes = "application/json") 
public String mappingConsumes() {
    log.info("mappingConsumes");
	return "ok"; 
}

HTTP 요청의 Content-Type 헤더를 기반으로 미디어 타입으로 매핑한다. 만약 맞지 않으면 HTTP 415 상태코드(Unsupported Media Type)을 반환한다.

예시)consumes

consumes = "text/plain"
consumes = {"text/plain", "application/*"}
consumes = MediaType.TEXT_PLAIN_VALUE

consume: 내가 소비하는 입장. 내가 해당 정보를 소비하고 있기 때문에 consume.

미디어 타입 조건 매핑 - HTTP 요청 Accept, produce

/**
 * Accept 헤더 기반 Media Type 
 * produces = "text/html" 
 * produces = "!text/html" * produces = "text/*" 
 * produces = "*\/*" 
 */
@PostMapping(value = "/mapping-produce", produces = "text/html") 
public String mappingProduces() {
    log.info("mappingProduces");
	return "ok"; 
}

HTTP 요청의 Accetp 헤더를 기반으로 미디어 타입으로 매핑한다. 만약 맞지 않으면 HTTP 406 상태코드(Not Acceptable)을 반환한다.
producers = "text/html": 클라이언트가 나는 text:html형식을 받아들일 수 있어, 하는 의미!

예시)

produces = "text/plain"
produces = {"text/plain", "application/*"}
produces = MediaType.TEXT_PLAIN_VALUE
produces = "text/plain;charset=UTF-8"

Content-Type 헤더 vs Accept 헤더

Content-Type 헤더
: HTTP 메시지(요청과 응답 모두)에 담겨 보내는 데이터의 형식을 알려주는 헤더. 대부분 Content-Type헤더를 기준으로 HTTP 메시지에 담긴 데이터를 파싱한다.
: HTTP 요청의 GET방식인 경우, 무조건 URL 끝에 쿼리스트링 형식으로 날아오기때문에 Content-Type의 헤더가 필요없다.(웹 서버에서도 method가 GET이면 key=value형식임을 유추할 수 있기 때문)
=> 따라서 Content-Type은 POST나 PUT처럼 메시지 바디에 데이터를 심어보낼때 중요하다.

Accept 헤더
: 브라우저(클라이언트)에서 웹 서버로 요청시 요청메시지에 담기는 헤더.
: "자신이 이러한 데이터 타입만 허용하겠다는 뜻"
: ex. Accept헤더:application/json = "나는 json 데이터만 처리할 수 있으니 json 데이터 형식으로 응답을 돌려주세요."

결론: 둘다 데이터타입을 다루는 헤더이지만 Content-Type헤더는 현재 전송하는 데이터가 어떤 타입인지에 대한 설명이고 Accept해더는 클라이언트가 서버에게 웬만하면 데이터 전송할때 이러이러한 타입만 가공해서 보내라 라고 하는 것과 같다.
출처:https://dololak.tistory.com/630

요청 매핑 -API 예시

회원 관리를 HTTP API로 만든다 생각하고 매핑을 어떻게 하는지 알아보자.
(실제 데이터가 넘어가는 부분은 생략하고 URL 매핑만)

회원관리 API

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

MappingClassController

package hello.springmvc.basic.requestmapping;

import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/mapping/users")
public class MappingClassController {
    /**
     * < 회원관리 API >
     * 회원목록조회:  	GET       /users
     * 회원등록:         POST     /users
     * 회원조회:         GET        /users/{userId}
     * 회원수정:         PATCH  /users/{userId}
     * 회원삭제:         DELETE /users/{userId}
     */

    @GetMapping
    public String user() {
        return "get users";
    }

    @PostMapping
    public String addUser(){
        return "post user";
    }

    @GetMapping("/{userId}")
    public String findUser(@PathVariable String userId) {
        return "get userId = " + userId;
    }

    @PatchMapping("/{userId}")
    public String updateUser(@PathVariable String userId) {
        return "update userId="+ userId;
    }

    @DeleteMapping("/{userId}")
    public String deleteUser(@PathVariable String userId) {
        return "delete userId="+userId;
    }

}

/mappin: 강의의 다른 예제들과 구분하기 위해 사용
@RequestMapping("/mapping/users"): 클래스 레벨에 매핑정보를 두면 메서드 레벨에서 해당 정보를 조합해서 사용한다.

Postman으로 테스트

HTTP 요청 - 기본, 헤더 조회

애노테이션 기반의 스프링 컨트롤러는 다양한 파라미터를 지원한다. 이번 시간에는 HTTP 헤더 정보를 조회하는 방법을 알아보자.
애노테이션 기반의 스프리 컨트롤러: RequestMappingHandlerAdapter
앞서 2장 서블릿에서도 HttpServletRequest를 통해 헤더정보를 불러오는 것을 연습했다. 스프링이 지원하는 것들을 통해 해당 정보들을 간단히 불러 올 수 있다. 이를 확인해보자!

RequestHeaderController

package hello.springmvc.basic.request;


import lombok.extern.slf4j.Slf4j;
import org.springframework.http.HttpMethod;
import org.springframework.util.MultiValueMap;
import org.springframework.web.bind.annotation.CookieValue;
import org.springframework.web.bind.annotation.RequestHeader;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.util.Locale;

@Slf4j
@RestController
public class RequestHeaderController {

    @RequestMapping("/headers")
    public String headers(HttpServletRequest request,
                          HttpServletResponse response,
                          HttpMethod httpMethod,
                          Locale locale,
                          @RequestHeader MultiValueMap<String, String> headerMap,
                          @RequestHeader("host") String host,
                          @CookieValue(value="myCookie", required = false) String cookie
                          ) {
        // 애노테이션 기반의 컨트롤러는 정말 다양한 파라미터를 받아들일 수 있다.
        // 인터페이스로 정형화 되어 있는것이 아니기 때문에, 스프링이 지원하는 것은 다 가능하다.

        log.info("request={}", request);
        log.info("response={}", response);
        log.info("httpMethod={}", httpMethod);
        log.info("locale={}", locale);
        log.info("headerMap={}", headerMap);
        log.info("header host={}", host);
        log.info("myCookie={}", cookie);

        return "ok";

    }
}

HttpServletRequest

HttpServletResponse

HttpMethod: HTTP 메서드를 조회한다. org.springframework.http.HttpMethod

Locale: Locale 정보를 조회한다.
스프링에는 여러가지 locale이 왔을때 어느 locale을 가장 우선으로 둘지 지정하는 localeResolver가 있음. locale을 쿠키나 세션에 두고 저장하면서서 사용하는 것이 가능. 기본은 http가 보내는 것을 사용하는 데 그것을 넘어 다른 방식으로 사용할 수도 있다. 더 알고싶으면 localeResolver에 대해 찾아보자!

@RequestHeader MultiValueMap<String, String> headerMap: 모든 HTTP 헤더를 MultiValueMap 형식으로 조회한다.

@RequestHeader("hose") String host

특정 HTTP 헤더를 조회한다.
속성: 필수 값 여부 = required/ 기본값 속성 = defaultValue

MultiValueMap

Map과 유사한데 하나의 키에 여러 값을 받을 수 있다.
HTTP header, HTTP 쿼리 파라미터와 같이 하나의 키에 여러 값을 받을 때 사용한다.
keyA=value1&vkeyA=value2

MultiValueMap<String, String> map = new LinkedMultiValueMap(); 
map.add("keyA", "value1");
map.add("keyA", "value2"); 

//[value1,value2]
List<String> values = map.get("keyA");

같은 헤더에 같은 값들이 들어올 수 있음. 그런 경우 MultiValueMap으로 받으면 된다. keyA를 꺼내면 배열이 반환되어 해당 key의 값들이 다 들어있다.(value1,value2)

@Slf4j

다음 코드를 자동으로 생성해서 로그를 선언해준다. 개발자는 편리하게 log라고 사용하면 된다.

private static final org.slf4j.Logger log =
org.slf4j.LoggerFactory.getLogger(RequestHeaderController.class);

참고

@Conroller의 사용 가능한 파라미터 목록은 다음 공식메뉴얼에서 확인할 수 있다.
https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-ann-
arguments

@Conroller 의 사용 가능한 응답값 목록은 다음 공식메뉴얼에서 확인할 수 있다.
https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-ann-return-types
각각의 애노테이션에 대한 메뉴얼 링크도 연결되어 있음.

서블릿에서의 헤더 정보 요청

 private void printHeaderUtils(HttpServletRequest request) {
        System.out.println("--- Header 편의 조회 start ---");
        System.out.println("[Host 편의 조회]");
        System.out.println("request.getServerName() = " +
                request.getServerName()); //Host 헤더
        System.out.println("request.getServerPort() = " +
                request.getServerPort()); //Host 헤더
        System.out.println();
        System.out.println("[Accept-Language 편의 조회]");
        request.getLocales().asIterator()
                .forEachRemaining(locale -> System.out.println("locale = " +
                        locale));
        System.out.println("request.getLocale() = " + request.getLocale());
        System.out.println();
        System.out.println("[cookie 편의 조회]");
        if (request.getCookies() != null) {
            for (Cookie cookie : request.getCookies()) {
                System.out.println(cookie.getName() + ": " + cookie.getValue());
            }
        }
        System.out.println();
        System.out.println("[Content 편의 조회]");
        System.out.println("request.getContentType() = " +
                request.getContentType());
        System.out.println("request.getContentLength() = " + request.getContentLength());
        System.out.println("request.getCharacterEncoding() = " +
                request.getCharacterEncoding());
        System.out.println("--- Header 편의 조회 end ---");
        System.out.println();
    }

엄청 복잡했다. 스프링에서 제공하는 기능덕에 매우 편리해졌음을 확인 가능하다.

HTTP 요청 파라미터 - 쿼리 파라미터, HTML Form

HTTP 요청 데이터 조회 - 개요

서블릿에서 학습했던 HTTP 요청 데이터를 조회하는 방법을 다시 떠올려보자. 그릐고 서블릿으로 학습했던 내용을 스프링이 얼마나 깔끔하고 효율적으로 바꾸어주는지 알아보자.

HTTP 요청 메시지를 통해 클라이언트에서 서버로 데이터를 전달하는 방법은 3가지가 있다.

GET- 쿼리파라미터

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

POST - HTML Form

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

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

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

요청 파라미터 - 쿼리 파라미터, HTML Form

HttpServletRequest의 request.getParameter()를 사용하면 다음 두 가지 요청 파라미터를 조회할 수 있다.

GET, 쿼리 파라미터 전송
예시:http://localhost:8080/request-param?username=hello&age=20

POST, HTML Form 전송
예시:

POST /request-param ...
content-type: application/x-www-form-urlencoded 

username=hello&age=20

GET 쿼리 파라미터 전송 방식이든 POST HTML Form 전송 방식이든 둘다 형식이 같으므로 구분 없이 조회할 수 있다. 이것을 간단히 요청 파라미터(request parameter) 조회라 한다.

지금부터 스프링으로 요청 파라미터를 조회하는 방법을 단계적으로 알아보자.

이번 단락에선, request.getParameter("변수명")를 통해 get, post방식의 데이터 조회를 확인한다.

RequestParamController

package hello.springmvc.basic.request;

import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@Slf4j
@Controller
public class RequestParamController {
    
    /*
    반환 타입이 없으면서 이렇게 응답에 값을 직접 집어넣으면, view 조회X
     */

    @RequestMapping("/request-param-v1")
    public void requestParamV1(HttpServletRequest request, HttpServletResponse response) throws IOException {
        String username = request.getParameter("username");
        int age = Integer.parseInt(request.getParameter("age"));
        log.info("username={}, age={}", username, age);

        response.getWriter().write("ok");
    }

}

request.getParameter()

여기서는 단순히 HttpServletRequest가 제공하는 방식으로 요청 파라미터를 조회햇다.

GET 실행

http://localhost:8080/request-param-v1?username=hello&age=20

POST Form 페이지 생성

먼저 테스트용 HTML Form을 만들어야 한다.

리소스는 /resources/static아래에 두면 스프링 부트가 자동으로 인식한다.
resurces의 static 안의 파일들은 외부에 공개된다.(그래서 index.html 파일도 공개가 된것)

main/resources/static/basic/hello-form.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head><body>
<form action="/request-param-v1" method="post">
    username: <input type="text" name="username" />
    age:     <input type="text" name="age" />
    <button type="submit">전송</button>
</form>
</body>
</html>

POST Form 실행
http://localhost:8080/basic/hello-form.html
username=kim, age=123

참고
Jar를 사용하면 webapp경로를 사용할 수 없다. 이제부터 정적 리소스도 클래스 경로에 함께 포함해야 한다.

HTTP 요청 파라미터 - @RequestParam

스프링이 제공하는 @RequestParam을 사용하면 요청 파라미터를 매우 편리하게 사용할 수 있다.

requestParamV2

    /**
     * @RequestParam 사용
     * - 파라미터 이름으로 바인딩
     * @ResponseBody 추가
     * - view 조회를 무시하고, HTTP message body에 직접 해당 내용 입력
     */
    @ResponseBody
    @RequestMapping("/request-param-v2")
    public String requestParamV2(
            @RequestParam("username") String memberName,
            @RequestParam("age") int memberAge) {

        log.info("username={}, age={}", memberName, memberAge);

        return "ok";
	}

@RequestParam: 파라미터 이름으로 바인딩
@ResponseBody: View 조회를 무시하고, HTTP messgae body에 직접 해당 내용 입력

@RequestParam의 name(value) 속성이 파라미터 이름으로 사용

@RequestParam("username") String memberNAme
=> request.getParameter("username")

💬 @Controller + String return "ok"; => ok라는 이름의 뷰를 찾는다.
✔️ 해결법1. 클래스 단위 애노테이션 @Controller -> @RestController로 수정
✔️ 해결법2. 메서드 위에 @ResponseBody 추가.
=> String문자를 http 응답메세지에 콱 넣어서 반환함. (@RestController와 같은 효과)

requestParamV3

    /**
     * @RequestParam 사용
     * HTTP 파라미터 이름이 변수 이름과 같으면 @RequestParam(name="xx") 생략 가능 
     */
    @ResponseBody
    @RequestMapping("/request-param-v3")
    public String requestParamV3(
            @RequestParam String username,
            @RequestParam int age) {

        log.info("username={}, age={}", username, age);
        return "ok";
    }

변수명을 통일하고, @RequestParam 애노테이션 뒤의 (name=username) 부분을 생략할 수 있다.

requestParamV4

    /**
     * @RequestParam 사용
     * String, int 등의 단순 타입이면 @RequestParam도 생략 가능
     */
    @ResponseBody
    @RequestMapping("/request-param-v4")
    public String requestParamV4(String username, int age) {

        log.info("username={}, age={}", username, age);
        return "ok";
    }

String, int, Integer등의 단순 타입이면 @RequestParam도 생략 가능.

주의
@RequestParam애노테이션을 생략하면 스프링MVC는 내부에서 required=false를 적용한다.

참고
이렇게 애노테이션을 완전히 생략해도 되는데, 너무 없는것도 약간 과할 수 있다. @RequestParam이 있으면 명확하게 요청 파라미터에서 데이터를 읽는 다는 것을 알 수 있다.

파라미터 필수 여부 - requestParamRequired

    /**
     * @RequestParam.required
     * /request-param-required -> username이 없으므로 예외
     *
     * 주의!
     * /request-param-required?username= -> 빈문자로 통과
     *
     * 주의!
     * /request-param-required
     * int age -> null을 int에 입력하는 것은 불가능, 따라서 Integer 변경해야 함
     * (또는 다음에 나오는 defaultValue 사용)
     */
    @ResponseBody
    @RequestMapping("/request-param-required")
    public String requestParamRequired(
            @RequestParam(required = true) String username,
            @RequestParam(required = false) int age) {

        log.info("username={}, age={}", username, age);
        return "ok";
    }

@RequestParam.required

파라미터 필수 여부
기본값이 파라미터 필수(true)이다.
username: true, age: false

요청1.
/request-param?age=20요청

username이 없으므로 400예외가 발생한다.

400 : 전송된 Request 문제 (Bad Request exception)

양방향 스펙을 설정할때 특정 변수를 필수라고 정한 값인데, 해당 값을 전송하지 않으면 BadRequest를 보내는것이 맞다.(HTTP 스펙을 준수하지 않은 것이므로)

요청2.
/request-param?username=kim요청

주의!- 기본형(primitive)에 null 입력
null을 int에 입력하는것은 불가능 (500예외 발생). 따라서 null을 받을 수 있는 Integer로 변경하거나, 또는 다음에 나오는 defaultValue 사용.

500 : 서버단의 문제 ( 권한 문제 )

요청3.
/request-parma?username= 요청

파라미터 이름만 있고 값이 없는 경우 -> 빈문자로 통과한다.
null, ""는 다르다.

기본 값 적용 - requestParamDefault

    /**
     * @ReuqestParam
     * - defaultValue 사용
     * 
     * 참고: defaultValue는 빈 문자의 경우에도 적용
     * /request-param-default?username=
     */
    @ResponseBody
    @RequestMapping("/request-param-default")
    public String requestParamDefault(
            @RequestParam(required = true, defaultValue = "guest") String username,
            @RequestParam(required = false, defaultValue = "-1") int age) {
      
        log.info("username={}, age={}", username, age);
        return "ok";
    }

값이 안들어오면(빈 문자의 경우) null로 설정되는것이 아니라 설정한 기본값이 적용 된다.(int의 경우에도 설정한 정수값이 사용되어 null이 입력되지 않으므로 오류가 나지 않는다.)
값을 입력하든 안하든 무조건 defaultValue로 설정한 값을 사용하므로 값을 사용하므로, Required 의미가 없다.
빈문자까지 커버할 수 있다는 것이 장점!!!

파라미터를 Map으로 조회하기 - requestParamMap

    /**
     * @RequestParam Map, MultiValueMap
     * Map(key=value)
     * MultiValueMap(key=[value1, value2, ...]) ex) (key=userIds, value=[id1, id2])
     */
    @ResponseBody
    @RequestMapping("/request-param-map")
    public String requestParamMap(@RequestParam Map<String, Object> paramMap) {
        log.info("username={}, age={}", paramMap.get("username"), paramMap.get("age"));
        return "ok";
    }

    @ResponseBody
    @RequestMapping("/request-param-multimap")
    public String requestParamMap(@RequestParam MultiValueMap<String, Object> paramMap) {
        log.info("username={}, age={}", paramMap.get("username"), paramMap.get("age"));
        return "ok";
    }

@RequestParam Map

Map(key=value)

@RequestParam MultiValueMap

MultiValueMap(key=[value1, value2, ...] ex) (key=userIds, value=[id1, id2])

파라미터의 값이 1개가 확실하다면 Map을 사용해도 되지만, 그렇지 않다면 MultiValueMap을 사용하자.
파라미터 값은 보통 하나만 넘긴다. 여러개 넘기는경우 거의 없다. ~~없는게 좋을거 같다 내가 생각해도.~~

실행
http://localhost:8080/request-param-map?username=1&username=2
http://localhost:8080/request-param-multimap?username=1&username=2

HTTP 요청 파라미터 - @ModelAttribute

실제 개발을 하면 요청 파라미터를 받아서 필욯나 객체를 만들고 그 객체에 값을 넣어주어야 한다. 보통 다음과 같이 코드를 작성할 것이다.

@RequestParam String username;
@RequestParma int age;

HelloData data = new HelloData();
data.serUesrname(username);
data.setAge(age);

스프링은 이 과정을 완전히 자동화해주는 @ModelAttribute기능을 제공한다.
먼저 요청 파라미터를 바인딩 받을 객체를 만들자.

HelloData

package hello.springmvc.basic;

import lombok.Data;

@Data
public class HelloData {
    private String username;
    private int age;

}

롬복 @Data

@Getter , @Setter , @ToString , @EqualsAndHashCode , @RequiredArgsConstructor를 자동으로 적용해준다.
toString도 적용하므로 HelloData 출력하면 예쁜 모양으로 출력해준다
~~너무편하고 좋다.~~

@ModelAttribute 적용 - modelAttributeV1

	 /**
     * @ModelAttribute 사용
     * 참고: model.addAttribute(helloData) 코드도 함께 적용됨, 뒤에 model을 설명할 때 자세히 설명
     */
    @ResponseBody
    @RequestMapping("/model-attribute-v1")
    public String modelAttributeV1(@ModelAttribute HelloData helloData) {
        log.info("username={}, age={}", helloData.getUsername(), helloData.getAge());
        return "ok";
    }

마치 마법처럼 HelloData 객체가 생성되고, 요청 파라미터의 값도 모두 들어가있다.

스프링 MVC는 @ModelAttribute가 있으면 다음을 실행한다.

HelloData 객체를 생성한다.
요청 파라미터의 이름으로 HelloData 객체의 프로퍼티를 찾는다. 그리고 해당 프로퍼티의 setter를 호출해서 파라미터의 값을 입력(바인딩)한다.
예) 파라미터 이름이 username이면 setUsername()메서드를 찾아서 호출하면서 값을 입력한다.
getXxx() => xxx, setXxx() => xxx로 변경해서 값을 가져옴.

프로퍼티
객체에 getUsername(), serUsername()메서드가 있으면, 이 객체는 username이라는 프로퍼티를 가지고 있다. username프로퍼티의 값을 변경하면 setUsername()이 호출되고, 조회하면 getUsername()이 호출된다.

바인딩 오류
age=age처럼 숫자가 들어가야 할 곳에 문자를 넣으면 BindException이 발생한다. 이런 바인딩 오류를 처리하는 방법은 검증 부분에서 다룬다.
정식 코드는 20, 30%정도. 오류 검증및 처리가 훨씬 오래걸린다. 중요하게 다뤄야 하는 부분이라 나중에 따로 자세히 설명할 것!

?age=abc 호출

바인딩(binding)
컴퓨터 프로그래밍에서 각종 값들이 확정되어 더 이상 변경할 수 없는 구속(bind)상태가 되는 것. 프로그램 내에서 변수, 배열, 라벨, 절차 등의 명칭, 즉 식별자(identifier)가 그 대상인 메모리 주소, 데이터형 또는 실제 값으로 배정되는 것이 이에 해당되며, 원시 프로그램의 컴파일링 또는 링크 시에 확정되는 바인딩을 정적 바인딩(static binding)이라 하고, 프로그램 실행 과정에서 바인딩 되는 것을 동적 바인딩(dynamic binding)이라고 한다. 프로그래머가 코딩을 해서 컴파일을 하게 되면 프로그래머가 값을 변경할 수 없는 상태가 되는데, 이걸 바인딩이라고 한다. 메모리에 값을 할당하는 것 또한 바인딩이라고 할수 있다. 쉽게 말하자면 바인딩이란 프로그램의 어떤 기본 단위가 가질 수 있는 구성요소의 구체적인 값, 성격을 확정하는 것을 말한다.

@ModelAttribute 생략 - modelAttributeV2

    /**
     * @ModelAttribute 생략 가능
     * String, int같은 단순 타입 = @RequestParam
     * 'argumet resolver'로 지정해둔 타입 외 = @ModelAttribute
     */
    @ResponseBody
    @RequestMapping("/model-attribute-v2")
    public String modelAttributeV2(HelloData helloData) {
        log.info("username={}, age={}", helloData.getUsername(), helloData.getAge());
        return "ok";
    }

@ModelAttribute는 생략할 수 있다. 그런데 @RequestParam도 생략할 수 있으니 혼란이 발생할 수 있다.

스프링은 해당 생략시 다음과 같은 규칙을 적용한다.

String, int, Integer같은 단순타입 = @RequestParam
나머지 = @ModelAttribute (argument resolver로 지정해둔 타입 외)

HttpServletResponse도 argument resolver 설정 예시 중 하나. argument resolver를 통해 특정 객체들이 예약이 되어 있다. 내가 직접 만든 객체들은 다 자동으로 modelAttribute로 적용이 됨. 당연히 내가 argument resolver에 추가하면 적용되지 않는다.

ModelAttribute(name="")으로 name도 적용가능. 그러나 요청이 올때 name과 관련없이, 객체의 멤버변수명과 일치하기만 하면 된다. name 적용 대상은 주로 view에 모델 넘길때 사용.

지금까지 요청 파라미터를 알아본것. 이제 http body에 직접 데이터가 넘어온 것을 알아볼 예정.

HTTP 요청 메시지 - 단순 텍스트

서블릿에서 학습한 내용을 떠올려보자.

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

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

요청 파라미터와 다르게, HTTP 메시지 바디를 통해 데이터가 직접 데이터가 넘어오는 경우는 @RequestParam, @ModelAttribute를 사용할 수 없다.(물론 HTML Form 형식으로 전달되는 경우는 요청 파라미터로 인정된다.)

먼저 가장 단순한 텍스트 메시지를 HTTP 메시지 바디에 담아서 전송하고, 읽어보자.
HTTP 메시지 바디의 데이터를 InputStream을 사용해서 직접 읽을 수 있다.

RequestBodyStringController

@Slf4j
@Controller
public class RequestBodyStringController {

   @PostMapping("/request-body-string-v1")
   public void requestBodyString(HttpServletRequest request, HttpServletResponse response) throws IOException {
       ServletInputStream inputStream = request.getInputStream();
       String messageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8);

       log.info("messageBody={}", messageBody);

       response.getWriter().write("ok");
   }
}

Postman을 통해서 테스트해보자.
POST 설정 + http://localhost:8080/request-body-string-v1
Body -> row, Text 선택

앞서 서블릿을 통해 우리가 직접 바디를 긁어오던 코드와 똑같다. 이제이걸 스프링이 어떻게 사용하기 용이하게 변경시켜주는지 살펴보자

Input, Output 스트림, Reader - requestBodyStringV2

    /**
     * InputStream(Reader): HTTP 요청 메시지 바디의 내용을 직접 조회
     * OutputStream(Writer): HTTP 응답 메시지의 바디에 직접 결과 출력
     */
    @PostMapping("/request-body-string-v2")
    public void requestBodyStringV2(InputStream inputStream, Writer responseWriter) throws IOException {
        String messageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8);
        log.info("messageBody={}", messageBody);
        responseWriter.write("ok");
    }

스프링 MVC는 다음 파라미터를 지원한다.

InputStream(Reader): HTTP 요청 메시지 바디의 내용을 직접 조회
OutputStream(Writer): HTTP 응답 메시지의 바디에 직접 결과 출력

HttpEntity - requestBodyStringV3

    /**
     * HttpEntity: Http header, body 정보를 편리하게 조회
     * - 메시지 바디 정보를 직접 조회(@RequetParma X, @ModelAttribute X)
     * - HttpMessageConverter 사용 -> StringHttpMessageConverter 적용
     *
     * 응답에서도 HttpEntity 사용 가능
     * - 메시지 바디 정보 직접 반환(view 조회 X)
     * - HttpMessageConverter 사용 -> StringHttpMessageConverter 적용
     */
    @PostMapping("/request-body-string-v3")
    public HttpEntity<String> requestBodyStringV3(HttpEntity<String> httpEntity) throws IOException {

        String messageBody = httpEntity.getBody(); //Http의 변환된 바디를 꺼낼 수 있음.
        log.info("messageBody={}", messageBody);

        return new HttpEntity<>("ok");
        // 파라미터로 bodymessage를 넣을 수 있음
    }

스프링 MVC는 다음 파라미터를 지원한다.
HttpEntity : HTTP header, body 정보를 편리하게 조회

메시지 바디 정보를 직접 조회
요청 파라미터를 조회하는 기능과 관계없음 (@RequetParma X, @ModelAttribute X)

HttpEntity 는 응답에도 사용 가능

메시지 바디 정보 직접 반환
헤더 정보 포함 가능
view 조회X

HttpEntity를 상속받은 다음 객체들도 같은 기능을 제공한다.
RequestEntity: HttpMethod, url정보가 추가, 요청에서 사용
ResponseEntity: HTTP 상태코드 설정 가능, 응답에서 사용

    @PostMapping("/request-body-string-v3")
    public HttpEntity<String> requestBodyStringV3(RequestEntity<String> requestEntity) throws IOException {

        String messageBody = requestEntity.getBody(); //Http의 변환된 바디를 꺼낼 수 있음.
        log.info("messageBody={}", messageBody);

        return new ResponseEntity<>("ok", HttpStatus.CREATED); // 상태코드를 넣을 수 있음.
    }

참고
스프링 mvc 내부에서 http 메시지 바디를 읽어서 문자나 객체로 변환해서 전달해주는데, 이때 HTTP 메시지 컨버터(HttpMessageConverter)라는 기능을 사용한다. 이것은 조금 뒤에 HTTP 메시지 컨버터에서 자세히 설명한다.

@RequestBody - requestBodyStringV4

종결버전. 이렇게 많이 쓴다.

    /**
     * @RequestBody
     * - 메시지 바디 정보를 직접 조회(@RequestParam X, @ModelAttribute X)
     * - HttpMessageConverter 사용 ->StringHttpMessageConverter 적용
     *
     * @ResponseBody
     * - 메시지 바디 정보 직접 반환(view 조회X)
     * - HttpMessageConverter 사용 -> StringHttpMessageConverter 적용
     */
    @ResponseBody
    @PostMapping("/request-body-string-v4")
    public String requestBodyStringV4(@RequestBody String messageBody) throws IOException {

        log.info("messageBody={}", messageBody);

        return "ok";
    }

@RequestBody
@RequestBody를 사용하면 HTTP 메시지 바디 정보를 편리하게 조회할 수 있다. 참거로 헤더 정보가필요하다면 HttpEntity를 사용하거나 @ReqjestHeader를 사용하면 된다. 이렇게 메시지 바디를 직접 조회하는 기능은 요청파라미터를 조회하는 @RequestParam, @ModelAttribute와는 전혀 관계가 없다.

요청 파라미터 vs Http 메시지 바디

요청파라미터를 조회하는 기능: @RequestParam , @ModelAttribute
HTTP 메시지 바디를직접조회하는기능: @RequestBody
(body추출 과정에서만) HttpMessageConverter라는 전혀 다른 메커니즘이 작동함. 지금까지 나열한 수동 작업들을 스프링 안의 얘가 자동으로 해준다.

요청 파라미터: 1.(get의 queryParameter) or 2.(POST로 HTML Form방식.content-type:x-www-urlencoded)으로 전송.
그 외는 전부 HttpEntity 같은것들을 이용해서 body에서 직접 꺼내야 함.

@ResponseBody
@ResponseBody를 사용하면 응답결과를 HTTP 메시지 바디에 직접 담아서 전달할 수 있다. 물론 이 경우에도 view를 사용하지 않는다.

HTTP 요청 메시지 - JSON

이번에는 HTTP API에서 주로 사용하는 JSON 데이터 형식을 조회해보자.
기존 서블릿에서 사용했던 방식과 비슷하게 시작해보자.

RequestBodyJsonController

package hello.springmvc.basic.request;

import com.fasterxml.jackson.databind.ObjectMapper;
import hello.springmvc.basic.HelloData;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;
import org.springframework.util.StreamUtils;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.ResponseBody;

import javax.servlet.ServletInputStream;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.nio.charset.StandardCharsets;

/**
 * {"username":"hello", "age":20}
 * content-type:application/json
 */
@Slf4j
@Controller
public class RequestBodyJsonController {

    private ObjectMapper objectMapper =new ObjectMapper();

    @PostMapping("/request-body-json-v1")
    public void requestBodyJsonV1(HttpServletRequest request, HttpServletResponse response) throws IOException {
        ServletInputStream inputStream = request.getInputStream();
        String messageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8);

        log.info("messageBody={}", messageBody);
        HelloData helloData = objectMapper.readValue(messageBody, HelloData.class);
        log.info("username={}, age={}", helloData.getUsername(), helloData.getAge());

        response.getWriter().write("ok");
    }
}

기존에 서블릿에서 학습한것과 다를게 없다.

HttpServletRequest를 사용해서 직접 HTTP 메시지 바디에서 데이터를 읽어와서, 문자로 변환한다.
문자로 된 JSON 데이터를 Jackson 라이브러리인 ojbectMapper를 사용해서 자바 객체ㅗ 변환한다.

Postman으로 테스트

POST http://localhost:8080/request-body-json-v1
raw, JSON, content-type: application/json
{"username":"hello", "age":20}

requestBodyJsonV2 - @RequestBody 문자 변환

/**
 * @RequestBody
 * HttpMessageConverter 사용 -> StringHttpMessageConverter 적용
 *
 * @ResponseBody
 * - 모든 메서드에 @ResponseBody 적용
 * - 메시지 바디 정보 직접 반환(view 조회X)
 * - HttpMessageConverter 사용 -> StringHttpMessageConverter 적용
 */
    @ResponseBody
    @PostMapping("/request-body-json-v2")
    public String requestBodyJsonV2(@RequestBody String messageBody) throws IOException {

        log.info("messageBody={}", messageBody);
        HelloData helloData = objectMapper.readValue(messageBody, HelloData.class);
        log.info("username={}, age={}", helloData.getUsername(), helloData.getAge());

        return "ok";
    }

이전 장처럼 기존의 코드에서 문자바꾸기 적용

이전에 학습했던 @RequestBody를 사용해서 HTTP 메시지에서 데이터를 꺼내고 messageBody에 저장한다.
문자로 된 JSON 데이터인 messageBody를 ObjectMapper를 통해서 자바 객체로 변환한다.

문자로 변환하고 다시 json으로 변환하는 과정이 불편하다. @ModelAttribute처럼 한번에 객체로 변환할 수는 없을까?
아, 이거 내가 굳이 objectMapper로 바꿔줘야 해? @ModelAttribute 할 때 되겨 편했잖아. 이건 그런거 없나? 됩니다요!v3

requestBodyJsonV3 - @RequestBody 객체 변환

@RequestBody 객체 파라미터

    /**
     * @RequestBody 생략 불가능(@ModelAttribute가 적용되어 버림)
     * HttpMessageConverter 사용 -> MappingJacson2HttpMessageConverter
     * (content-type:application/json)
     */
    @ResponseBody
    @PostMapping("/request-body-json-v3")
    public String requestBodyJsonV3(@RequestBody HelloData helloData) throws IOException {
        log.info("username={}, age={}", helloData.getUsername(), helloData.getAge());

        return "ok";
    }

@RequestBody 객체 파라미터

@RequestBody HelloData data
@RequestBody에 직접 만든 객체를 지정할 수 있다.

HttpEntity, @ResponseBody를 사용하면 HTTP메시지 컨버터가 HTTP 메시지 바디의 내용을 우리가 원하는 문자나 객체 등으로 변환해준다. HTTP 메시지 컨버터는 문자 뿐만 아니라 JSON도 객체로 변환해주는데, 우리가 방금 V2에서 했던 작업을 대신 처리해준다. 자세한 내용은 뒤에 HTTP 메시지 컨버터에서 다룬다.

HttpEntity<HelloData> 이렇게 쓰면 HelloData 객체에 맞춰 반환해준다. HttpMessageConverter가 JSON이면 HelloData helloData = objectMapper.readValue(messageBody, HelloData.class); 코드를 대신 실행해주고 그렇게 생성된 객체를 helloData에 대신 넣어주는 것. 문자를 컨버터하는 컨버터도 있고 json을 컨버터해주는것이 또 따로있다.

@RequestBody는 생략 불가능
@MocelAttribute에서 학습한 내용을 떠올려보자.

스프링은 @ModelAttribute, @RequestParam과 같은 해당 애노테이션을 생략시 다음과 같은 규칙을 적용한다.

String, int, Integer과 같은 단순타입 = @RequestParam
나머지 = @ModelAttribute (argument resolver로 지정해둔 타입 외)
생략하면 @ModelAttribute가 붙어버린다. 따라서 생략하면 HTTP 메시지 바디가 아니라 요청 파라미터를 처리하게 된다.

주의
HTTP 요청시에 content-type이 applicatoin/json인지 꼭! 확인해야 한다. 그래야 JSON을 처리할 수 있는 HTTP 메시지 컨버터가 실행된다.

requestBodyJsonV4 - HttpEntity

물론 앞서 배운 것과 같이 HttpEntity를 사용해도 된다.

    @ResponseBody
    @PostMapping("/request-body-json-v4")
    public String requestBodyJsonV4(HttpEntity<HelloData> helloData) throws IOException {
        HelloData data = helloData.getBody();
        // getBody하면 제네릭 타입이 반환됨.
        log.info("username={}, age={}", data.getUsername(), data.getAge());

        return "ok";
    }

requestBodyJsonV5

    /**
     * @RequestBody 생략 불가능(@ModelAttirbute가 적용되어 버림)
     * HttpMessageConverter 사용 -> MappingJacson2HttpMessageConverter
     * (content-type:applicaion/json)
     *
     * @ResponseBody 적용
     * - 메시지 바디 정보 직접 반환(view 조회X)
     * - HttpMessageConverter 사용 -> MappingJackson2HttpMessageConverter적용
     * (Accept: application/json)
     */
    @ResponseBody
    @PostMapping("/request-body-json-v5")
    public HelloData requestBodyJsonV5(@RequestBody HelloData helloData) throws IOException {
        log.info("username={}, age={}", helloData.getUsername(), helloData.getAge());

        return helloData;
    }

@ResponsBody
응답의 경우에도 @ResponseBody를 사용하면 해당 객체를 HTTP 메시지 바디에 직접 넣어줄 수 있다. 물론 이 경우에도 HttpEntity를 사용해도 된다.

@RequestBody 요청

JSON 요청 -> HTTP 메시지 컨버터 -> 객체

@RequestBody 응답

객체 -> HTTP 메시지 컨버터 -> JSON 응답

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

3가지 종류의 응답 데이터

응답 데이터는 이미 앞에서 일부 다룬 내용들이지만, 응답 부분에 초점을 맞추어서 정리해보자.
스프링(서버)에서 응답 데이터를 만드는 방법은 크게 3가지이다.

정적 리소스

예) 웹 브라우저에 정적인 HTML, css, js를 제공할때는, 정적 리소스를 사용한다.

뷰 템플릿 사용

예) 웹 브라우저에 동적인 HTML을 제공할 때는 뷰 템플릿을 사용한다.

HTTP 메시지 사용

HTTP API를 제공하는 경우에는 HTML이 아니라 데이터를 전달해야 하므로, HTTP 메시지 바디에 JSON과 같은 형식으로 데이털르 실어 보낸다.

정적 리소스

스프링부트는 클래스패스의 다음 디렉토리에 있는 정적 리소스를 제공한다.
/static, /public, /resources, /META-INF/resources/

src/main/resources는 리소스를 보관하는 곳이고, 또 클래스패스의 시작 경로이다. 따라서 다음 디렉토리에 리소스를 넣어두면 스프링부트가 정적 리소스로 서비스를 제공한다.

static 안에 들어있는 파일들은 스프링 부트가 정적 리소스로 제공한다.
public등 위에 나열한 이름들은 다 가능. 해당 주소 안에 있으면 웹 브라우저를 통해 클라이언트가 실행 가능하다.

정적 리소스 경로
src/main/reources/static

다음 경로에 파일이 들어있으면 (src/main/resources/static/basic/hello-form.html) 웹 브라우저에서 다음과 같이 실행하면 된다. http://localhost:8080/basic/hello-form.html 호출.

정적 리소스는 해당 파일을 변경 없이 그대로 서비스하는 것이다.

뷰 템플릿

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

스프링 부트는 기본 뷰 템플릿 경로를 제공한다.

뷰 템플릿 경로
src/main/resources/templates

뷰 템플릿 생성

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<p th:text="${data}">empty</p>
</body>
</html>

<html xmlns:th="http://www.thymeleaf.org">: 기본으로 넣는다.
<p th:text="${data}">empty</p>
:<th:text>코드 사용시 model에서 data라는 키의 값을 꺼내서 empty 부분을 data의 값으로 치환해서 보여준다.

ResponseViewController - 뷰 템플릿을 호출하는 컨트롤러

package hello.springmvc.basic.response;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.servlet.ModelAndView;

@Controller
public class ResponseViewController {

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

        return mav;
    }

//    @ResponseBody
    @RequestMapping("/response-view-v2")
    public String responseViewV2(Model model) {
        model.addAttribute("data", "hello!");
        return "response/hello";
    }

    @RequestMapping("/response/hello")
    public void responseViewV3(Model model) {
        model.addAttribute("data", "hello!");
    }

}

v1
ModelAndView에 논리주소와 객체를 넣고 반환.
v2: String을 반환하는 경우 - View 혹은 HTTP 메시지

@Controller + String 반환 = String 값이 뷰의 논리적이름이 된다.
따라서 response/hello로 뷰 리졸버가 실행되어서 뷰를 찾고, 렌더링 한다.
만약 @ResponseBody가 붙으면 뷰 리졸버를 실행하지 않고, HTTP 메시지 바디에 직접 response/hello라는 문자가 응답된다.

v3: void를 반환하는 경우

@Controller를 사용하고, HttpSErvletResponse,OutputStream(Writer)같은 HTTP 메시지 바딜르 처리하는 파라미터가 없으면 요청 URL을 참고해서 논리 뷰 이름으로 사용
요청 URL: /reponse/hello
실행: templates/response/hello.html
참고로 이 방식은 명시성이 너무 떨어지고 이렇게 딱 맞는 경우도 많이 없어서, 권장하지 않는다.
스프링이 관례적으로 생략할 수 있도록 도와주는 것. Controller의 경로 이름 == view의 논리적 이름 + 반환x = 넘겨주는 String이 논리적 뷰의 이름으로 진행됨

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

Thymeleaf 스프링 부트 설정

다음 라이버리를 추가하면 스프링 부트가 자동으로 ThymeleafViewReslover와 필요한 스프링 빈을 등록한다. 그리고 다음 설정도 사용한다. 이 설정은 기본 값이기 때문에 변경이 필요할 때만 설정하면 된다.

build.gradle

`implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'`

application.properties

spring.thymeleaf.prefix=classpath:/templates/ 
spring.thymeleaf.suffix=.html

타임리프 설정 기본값은 입력 안해도 설정됨. 변경하고 싶은 경우에만 설정값을 직접 입력하고 수정해주면 된다.

참고
스프링부트의 타임리프 관련 추가 일정은 다음 공식 사이트를 참고하자.(페이지 안에서 thymeleaf 검색)
https://docs.spring.io/spring-boot/docs/2.4.3/reference/html/appendix-application-properties.html#common-application-properties-templating

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

HTTP API를 제공하는 경우에는 HTML이 아니라 데이터를 전달해야 하므로, HTTP 메시지 바디에 JSON 같은 형식으로 데이터를 실어 보낸다. HTTP 요청에서 응답까지 대부분 다루었으므로 이번에는 정리를 해보자.

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

ResponseBodyController

package hello.springmvc.basic.response;

import hello.springmvc.basic.HelloData;
import lombok.extern.slf4j.Slf4j;
import org.apache.coyote.Response;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.bind.annotation.ResponseStatus;
import org.springframework.web.bind.annotation.RestController;

import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@Slf4j
@Controller
//@ResponseBody
@RestController
public class ResponseBodyController {

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

    // 좀더 단순하게 스프링에서 제공하는 방식

    /**
     * HttpEntity, ResponseEntity(Http Status 추가)
     */
    @GetMapping("/response-body-string-v2")
    public ResponseEntity responseBodyV2() {
        return new ResponseEntity<>("ok", HttpStatus.OK);
    }

    // 거기서 더 편하게
    @GetMapping("/response-body-string-v3")
    @ResponseBody
    public String responseBodyV3() {
        return "ok";
    }


    // 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);
    }

    @ResponseStatus(HttpStatus.OK)
    @ResponseBody
    @GetMapping("/response-body-json-v2")
    public HelloData responseBodyJsonV2() {
        HelloData helloData = new HelloData();
        helloData.setUsername("userA");
        helloData.setAge(20);
        return helloData;
    }
    // 이 경우에는 상태메시지를 내가 바꿀 수 없음. => @ResponseStatus 기능을 제공.
}

resonseBodyV1
서블릿을 직접 다룰 때 처럼 HttpServletResponse 객체를 통해서 HTTP 메시지바디에 직접 ok응답 메시지를 전달한다.
response.getWriter().writer("ok");

responseBodyV2
ResponseEntity 엔티티는 HttpEntity를 상속받았는데, HttpEntity는 HTTP 메시지의 헤더, 바디 정보를 가지고 있다. ResponseEntity는 여기에 더해서 HTTP 응답 코드를 설정할 수 있다.
HttpStatus.CREATED로 변경하면 201 응답이 나가는것을 확인할 수 있다.

responseBodyV3
@ResponseBody를 사용하면 view를 사용하지 않고, HTTP 메시지 컨버터를 통해서 HTTP 메시지를 직접 입력할 수 있다. ResponseEntity도 동일한 방식으로 동작한다.

< JSON의 경우 >
responseBodyJsonV1
ResponseEntity를 반환한다. HTTP 메시지 컨버터를 통해서 JSON 형식으로 변환되어 반환된다.

responseBodyJsonV2
ResponseEntity는 HTTP 응답 코드를 설정할 수 있는데, @ResponseBody를 사용하면 이런 것을 설정하기 까다롭다. @ResponseStatus(HttpStatus.OK) 애노테이션을 사용하면 응답 코드도 설정할 수 있다.

물론 애노테이션이기 때문에 코드를 동적으로 변경할 수는 없다. 프로그램 조건에 따라서 동적으로 변경하려면 ResonseEntity를 사용하면 된다.

@RestController

@ResponseBody: 클래스 단위로 붙일 수 있음. 그럼 모든 메서드에 다 적용된다.
@ResController: @Controller + @ResponseBody
따라서, @Controller 대신에 @RestController 애노테이션을 사용하면, 해당 컨트롤러에 모두 @ResponseBody가 적용되는 효과가 있다. 따라서 뷰 템플릿을 사용하는 것이 아니라, HTTP 메시지 바디에 직접 데이터를 입력한다. 이름 그대로 Rest API(HTTP API)를 만들때 사용하는 컨트롤러이다.

HTTP 메시지 컨버터

뷰 템플릿으로 HTML을 생성해서 응답하는 것이 아니라, HTTP API처럼 JSON데이터를 HTTP 메시지 바디에서 직접 읽거나 쓰는 경우 HTTP 메시지 컨버터를 사용하면 편리하다.
과거 서블릿에서 response.getWriter.write("ok") 이런식으로 구현하는거 너무 힘들고 번거로웠음. 그런 부분들을 HTTP 메시지 컨버터가 대신 수행해준다!

HTTP 메시지 컨버터를 설명하기 전에 잠깐 과거로 돌아가서 스프링 입문 강의에서 설명했던 내용을 살펴보자.

@ResponseBody 사용 원리

웹브러우저에서 요청이 오면 컨트롤러가 호출되고, @ResponseBody가 있으면 HttpMessageConverter가 작동하여 json으로 나갈지, String으로 나갈지 결정해서 hello return값을 반환함(여기선 객체로 반환)

@ResponseBody를 사용

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

참고: 응답의 경우 클라이언트의 HTTP Accept 헤더와 서버의 컨트롤러 반환 타입 정보 두을 조합해서 (사실은 몇개 더 고려함) HttpMessageConverter가 선택된다.

이제 다시 돌아와서,

스프링 MVC는 다음의 경우에 HTTP 메시지 컨버터를 적용한다.

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

HTTP 메시지 컨버터는 HTTP 요청, HTTP 응답 둘 다 사용된다. (양방향)

HTTP 메시지 컨버터 인터페이스

http 메시지 컨버터는 인터페이스로 되어 있음. (json처리, String처리 등등 여러가지 종류가 있음. 이 여러종류들을 아우르는 부모 인터페이스가 존재)

org.springframework.http.converter.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)
            throws IOException, HttpMessageNotReadableException;

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

HTTP 메시지 컨버터는 HTTP 요청, HTTP 응답 둘 다 사용된다.

canRead(), canWrite(): 메시지 컨버터가 해당 클래스, 미디어 타입을 지원하는지 체크
read(), write(): 메시지 컨버터를 통해서 메시지를 읽고 쓰는 기능.

스프링 부트 기본 메시지 컨버터

스프링 부트는 기본적으로 올라올때 몇가지 메시지 컨버터들을 등록해놓음.
(일부 생략)

0 = ByteArrayHttpMessageConverter
1 = StringHttpMessageConverter
2 = MappingJackson2HttpMessageConverter

스프링 부트는 다양한 메시지 컨버터를 제공하는데, 대상 클래스 타입과 미디어 타입 둘을 체크해서 사용 여부를 결정한다. 만약 만족하지 않으면 다음 메시지 컨버터로 우선순위가 넘어간다.
미디어 타입 : Http 요청인 경우에는 Content-Type.

몇가지 주요한 메시지 컨버터를 알아보자.

ByteArrayHttpMessageConverter

클래스 타입:byte[], 미디어 타입 */* (다 된다는 의미)
요청 예) @RequestBody byte[] data
응답 예) @ResponseBody return byte[] 쓰기 미디어타입 applicaion/octet-stream
컨트롤러에서 requestbody라고 하고, byte[] 선언해서 받으면 http message body에 있는 것들을 그대로 byte로 받을 수 있음.

StringHttpMessageConverter

클래스 타입: String, 미디어 타입 */*
요청 예) @RequestBody String data
응답 예) @ResponseBody return "ok쓰기 미디어타입 text/plain
byte로 오는것을 String으로 convert해서 넣어줌

MappingJackson2HttpMessageConverter: application/json

클래스 타입: 객체 또는 HashMap, 미디어 타입 application/json 관련
요청 예) @RequestBody HelloData data
응답 예) @ResponseBody return helloData쓰기 미디어타입 application/json관련

항상 http 메시지 바디에 데이터가 있으면 컨텐트 타입을 지정해줘야 한다. 요청메시지든 응답 메시지든.

StringHttpMessageConverter

content-type: applicaion/json

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

이런 요청이 오면,

스프링 부트 기본 메시지 컨버터들을 0번부터 돌아가면서 확인한다.
@Request String => 0: byte 아님. 1: String 맞음!
StringHttpMessageConverter 의 미디어 타입이 다 수용가능한 */* 이므로 커버 가능함.
해당 메시지 컨버터 채택!

💬 어? Content-Type이 application/json인데요?
✔️@RequestBody String인 시점에서 MappingJackson2HttpMessageConverter은 우선순위가 밀립니다. 우선순위 높은 StringHttpMessageConverter가 먼저 채택되게 됨니다.

MappingJackson2HttpMessageConverter

content-type: application/json

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

클래스타입: 객체 -> 0byte 아님. 1String아님. 2번 객체 맞음!
MappingJackson2HttpMessageConverter의 미디어 타입: application/json으로 일치함.
MappingJackson2HttpMessageConverter 채택
객체 읽어서 HelloData 만들어준다.

content-type: text/html

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

클래스 타입: 0byte 탈락, 1String 탈락, 2객체 맞음!
MappingJackson2HttpMessageConverter의 미디어 타입 applicaion/json이 아님.
탈락! 제대로 작동 못함!

Http 요청 데이터 읽기

HTTP 요청이 오고, 컨트롤러에서 @RequestBody , HttpEntity파라미터를 사용한다.
메시지 컨버터가 메시지를 읽을 수 있는지 확인하기 위해 canRead() 를 호출한다.
- 대상 클래스 타입을 지원하는가.
  - 예) @RequestBody의 대상 클래스( byte[] , String , HelloData )
- HTTP 요청의 Content-Type 미디어타입을 지원하는가.
  - 예) text/plain , application/json , */*
canRead()조건을 만족하면 read()를 호출해서 객체 생성하고, 반환한다.
메시지 컨버터 후보들을 돌아가면서 canRead()할 수 있는지 확인한다.

Http 응답 데이터 생성

컨트롤러에서 @ResponseBody, HttpEntity로 값이 반환된다.
메시지 컨버터가 메시지를 쓸 수 있는지 확인하기 위해 canWrite()를 호출한다.
- 대상 클래스 타입을 지원하는가.
  - 예) return의 대상 클래스
- HTTP 요청의 Accetp 미디어 타입을 지원하는가.(더 정확히는 @RequestMapping의 produces)
  - 예) text/plain , application/json , */*
canWrtie() 조건을 만족하면 write()를 호출해서 HTTP 응답 메시지 바디에 데이터를 생성한다.
procues 생성하면 이거 쓰고, 안하면 accept 미디어 타입을 적용한다.

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

RequestMappingHandlerAdapter. 컨트롤러가 처리해주는 바로 그것.
그렇다면 HTTP 메시지 컨버터는 스프링 MVC 어디쯤에서 사용되는 것일까? 다음 그림에서는 보이지 않는다.

springMVC 구조

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

지금까지 당연하게 생각했던 것들에 한 번 의문을 가져보자. 앞서 진행했던 코드다. requestBodyJsonV1메서드의 파라미터인 HttpServletRequest는 누가 넣어줬을까? @ResponseBody String messageBody는? 누가 당연하다는 듯 byte를 String으로 바꿔서 넣어줬을까? 나는 넣은적 없다. 당연한 것은 없음에도 불구하고 나는 당연하다는 듯이 파라미터들을 요구하고, 파라미터의 변형을 요구했다. 그리고 누군가 소리소문 없이 그 일들을 수행하고 있었다! 누가 일일이 파라미터들을 정제하고 삽입해주었을까?
=> 바로 Argument Resolver 다!!

RequestMappingHandlerAdatper 동작 방식

ReuqestMappingHandlerAdatper는 ArgumentResolver를 호출해서 HttpServletRequest 객체 가져다 줄수 있어? HttpServletResponse도 가져다 줄수있어? 하고 물어봄. 그럼 ArgumentResolver가 객체를 가져다 줌. 특히 @RequestBody String messageBody 같은거 ArgumentResolver가 다 만들어서 가져다줌. 그래서 다 가져다 주면 핸들러어댑터가 "나 준비 다 됐어!"하며 핸들러를 호출하고 파라미터를 건내줌.

Argument Resolver

생각해보면, 애노테이션 기반의 컨트롤러는 매우 다양한 파라미터를 사용할 수 있었다.
HttpServletRequest,Model은 물론이고, @RequestParam, @ModelAttribute같은 애노테이션 그리고 @RequestBody, HttpEntity같은 http 메시지를 처리하는 부분까지 매우 큰 유연함을 보여주었다. 이렇게 파라미터를 유연하게 처리할 수 있는 이유가 바로 ArgumentResolver 덕분이다.

애노테이션 기반 컨트롤러를 처리하는 ReuqestMappingHandlerAdapter는 바로 이 ArgumentResolver를 호출해서 컨트롤러(핸들러)가필요로 하는 다양한 파라미터의 값(객체)을 생성한다. 그리고 이렇게 파라미터의 값이 모두 준비되면 컨트롤러를 호출하면서 값을 넘겨준다.

스프링은 30개가 넘는 ArgumentResolver를 기본으로 제공한다. 어떤 종류들이 있는지 살짝 코드로 확인만 해보자.

참고: 가능한 파라미터 목록은 다음 공식 메뉴얼에서 확인할 수 있다.
https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-ann-arguments

정확히는 HandlerMethodArgumentResolver인데 줄여서 ArgumentResolver라고 부른다.

public interface HandlerMethodArgumentResolver {
    
    boolean supportsParameter(MethodParameter parameter);
    
    @Nullable
    Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
                           NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception;
}

동작 방식
ArgumentResolver의 supportsParameter()를 호출해서 해당 파라미터를 지원하는지 체크하고, 지원하면 resolveArgument()를 호출해서 실제 객체를 생성한다. 그리고 이렇게 생성된 객체가 컨트롤러 호출 시 넘어가는 것이다.

그리고 원한다면 여러분이 직접 이 인터페이스를 확장해서 원하는 ArgumentResolver를 만들 수도 있다. 실제 확장하는 예제는 향후 로그인 처리에서 진행하겠다.
~~헉..정말? 너무 설렌다~~

ReturnValueHandler
HandlerMethodReturnValueHandler를 줄여서 ReturnValueHandler라 부른다. ArgumentResolver와 비슷한데, 이것은 응답값을 변환하고 처리한다.
Method라는 단어는 컨트롤러들이 Method단위로 작동해서 붙은 이름.

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

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

참고
가능한 응답 값 목록은 다음 공식 메뉴얼에서 확인할 수 있다.
https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-ann-return-types

Http 메시지 컨버터

Http 메시지 컨버터 :argumentResolver가 사용하는 것.

HTTP 메시지 컨버터 위치

Argument Resolver 중에서 @RequestBody, HttpEntity 처리해야하는 리졸버인 경우에 한해서 Argument Resolver가 로직을 다 처리하는 것이 아니라 HTTP 메시지 컨버터에게 물어본다. "이거 처리해야 하는데, http 메시지 바디에 있는거 꺼내서 너가 json이나 이런거 처리해줄 수 있어?" 하고 물어 보면 http 메시지 컨버터가 "어, 나 할수있어" 하고 바꿔주는 것.

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

요청의 경우 @RequestBody를 처리하는 ArgumentResolver가 있고, HttpEntity를 처리하는 ArgumentResolver가 있다. 이 ArgumentResolver들이 HTTP 메시지 컨버터를 사용해서 필요한 객체를 생성하는 것이다.(어떤 종류가 있는지 코드로 살짝 확인해보자.)

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

스프링 MVC는 @RequestBody @ResponseBody 가 있으면 RequestResponseBodyMethodProcessor (ArgumentResolver) HttpEntity 가있으면 HttpEntityMethodProcessor (ArgumentResolver)를사용한다.

참고
HttpMessageConverter를 구현한 클래스를 한번 확인해보자.
@RequestBody가 들어오면, argumentResolver 안의 supportParameter()를 통해 해당 객체가 담당하는 건지 확인해보고, readWithMessageConverters()에서 아까 본 메세지 컨버터들(ex.StringHttpMessageConverter, MappingJackson2HttpMessageConverter)을 loop 돌리면서 적절한 것을 골라 사용한다. 해당 HTTP 메시지 컨버터가 read()를 사용해서 메시지를 읽어온다.

확장

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

HandleMethodArgumentResolver
HandleMethodReturnValueHandler
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) {
			 //...
		 }
	 };
}

정리

bien

Good Luck!

이전 포스트

[Spring] #5. 스프링 MVC - 구조 이해 (김영한_인프런_스프링MVC1)

다음 포스트