[Spring] HTTP 요청 파라미터, 응답 데이터 생성, HttpMessageConverter와 ArgumentResolver

- 김영한 님의 '스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술'을 보고 정리한 글입니다 😊

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

---

- 지난 포스팅과 이어집니다 :D

[Spring] DispatcherServlet의 동작 과정과 HanderMapping, HandlerAdapter, @RequestMapping

- 지난 포스팅에서는 DispatcherServlet의 동작 과정 및 Spring MVC의 기본 구조에 대해 알아보았다.

- 이번 포스팅에서는 본격적으로 Spring MVC에서 제공하는 기능에 대해서 알아보자. 

 

 

| Spring MVC - 기본 기능

- SpringMVC에서 제공하는 기본 기능에 대해서 알아보자.

 

[MappingController.java]

@RestController
public class MappingController {
    private Logger log = LoggerFactory.getLogger(getClass());

    @RequestMapping("/hello-basic")
    public String helloBasic() {
        log.info("helloBasic");
        return "ok";
    }
}

- @RestController = @Controller + @ResponseBody

- 반환 값을 HTTP 메시지 바디에 바로 입력하기 때문에, 실행 결과로 페이지에 ok라는 글자가 뜨게 된다.

- 단순히 @RequestMapping을 사용하면 Http 메서드와 무관하게 호출된다. (어떤 메서드든 허용)

 

 

✔ @GetMapping

@RequestMapping(value = "/mapping-get-v1", method = RequestMethod.GET)
public String mappingGetV1() {
    log.info("mappingGetV1");
    return "ok";
}

@GetMapping(value = "/mapping-get-v2")
public String mappingGetV2() {
    log.info("mapping-get-v2");
    return "ok";
}

- 참고로, 이 두 가지는 완전히 동일하다. 그러나, 웬만하면 두 번째 방법을 사용하는 게 더 직관적이다.

- 이러면 해당 HTTP 메서드로 들어오는 요청만 받게 된다.

 

 

✔ @PathVariable

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

- 이런 식으로 경로 변수도 사용할 수 있다.

⭐ data대신에 userId라고 사용하면 @Pathvariable의 파라미터를 생략할 수 있다. (그래도 웬만하면 써주는 게 보기는 편하다)

- @PathVariable은 다중으로도 사용 가능하다. 이름만 맞춰주면 된다!

 

 

✔ @GetMapping - params

@GetMapping(value = "/mapping-param", params = "mode=debug")
public String mappingParam() {
    log.info("mappingParam");
    return "ok";
}

- 잘 사용하지는 않지만, 파라미터에 mode=debug라는 게 들어가야 해당 메서드가 호출된다.

    - 즉, 단순히 /mapping-param으로는 호출되지 않고 /mapping-param?mode=debug로 해야 호출된다.

- 특정 파라미터가 있을 때 호출될 수 있도록 조건을 덧붙이는 것이다.

- 참고로, !mode나 mode!=debug 같이 조건을 줄 수도 있으며 다중 조건도 가능하다.

 

 

✔ @GetMapping - headers

@GetMapping(value = "/mapping-header", headers = "mode=debug")
public String mappingHeader() {
    log.info("mappingHeader");
    return "ok";
}

- 혹은, 특정 HTTP 헤더가 있는지 없는지에 따라서도 가능하다.

 

✔ 미디어 타입 조건 매핑 

@PostMapping(value = "/mapping-consume", consumes = "application/json")
public String mappingConsumes() {
    log.info("mappingConsumes");
    return "ok";
}

- 이런 식으로 content-type을 기반으로 미디어 타입을 매핑할 수 있다.

(클라이언트가 서버에게 보내는 데이터 타입의 명시)

- 미디어 타입이 다르면 415가 나온다 (Unsupported Media Type)

- "application/*" 이런 식으로도 표현이 가능하다. 

- 여러 개도 가능하다. consumes = {"text/plain", "application/*"}

- Content-type의 경우 해당 헤더에 데이터가 오지 않았을 때 서버 측에서 거절할 수 있도록 하는 매개체 정도로 생각하면 된다.

@PostMapping(value = "/mapping-produce", produces = "text/html")
public String mappingProduces() {
    log.info("mappingProduces");
    return "ok";
}

- 반대로 Accept 헤더를 기반으로 미디어 타입을 매핑할 수 있다.

(서버가 클라이언트에게 반환하는 데이터 타입 명시)

-  Accept의 경우 클라이언트가 응답을 받을 때 원하는 데이터 타입을 지정하는 것이다.

- 맞지 않을 경우 406가 나온다 (Not Acceptable)

 

 

✔ ⭐ API 예시 

- 회원 목록 조회 (GET) /users

- 회원 등록 (POST) /users

- 회원 조회 (GET) /users/id/1

- 회원 수정 (PATCH) /users/id/1

- 회원 삭제 (DELETE) /users/id/1

 

 

🚩 RESTful API 설계 (내가 보려고 정리..)

-  URI 규칙

    - 마지막에 /을 붙이기

    - _대신에 -를 사용하기 (소문자 사용, -으로 잇는 형태)

    - 메서드의 행위 (get, delete...)는 uri에 포함하지 않을 것.

 

- POST, GET, PUT, DELETE는 반드시 사용, OPTIONS, HEAD, PATCH도 추가적으로 사용할 것.

    - options는 현재 end-point가 제공 가능한 api method를 응답한다.

    - head는 요청에 대한 header 정보만 응답하며 body가 없다.

    - 자원의 일부를 수정할 때는 put 대신에 patch를 사용한다.

 

의미에 맞는 Http status를 리턴하며, status 만으로 상태 에러를 나타낼 것. (응답 객체에 중복 표시 X)

: 이거는 좀 애매한데, 400 같은 경우는 파라미터 위치나 사용자 입력 값, 에러 이유를 반드시 알리는 게 좋다.

ex) location (파라미터 위치 - body, path, query) / param (어떤 쿼리 파라미터?) / value (사용자 입력값) / msg (오류 메시지)

500 에러의 경우 사용자에게 나타내서는 안 된다. API server는 발생 가능한 모든 에러를 핸들링할 것. (웹 서버 에러 제외)

 

- 구성 요소

    - 변경될 리소스의 상태 관계 (rel) : self -> 현재 자신의 URL

    - 요청 URL (href)

    - 요청 Method (method)

 

그 외에 더 자세한 사항은 아래 링크를 참고하는 게 좋을 것 같다 :D

RESTful API 설계 가이드

---

 

| HTTP 요청 - 기본, 헤더 조회

- Http 헤더 정보를 조회해보자.

@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";
}

- 여기서 @RequestHeader를 사용하면 MultiValueMap 형식으로 HTTP 헤더를 조회할 수 있다.

    - MultiValueMap은 하나의 키에 여러 값을 받을 때 사용한다.

    - HTTP header나 HTTP 쿼리 파라미터처럼 하나의 키에 여러 값을 받을 때 사용한다.

    - map.get("a")라고 했을 때 List형으로 반환된다!

- 혹은, 파라미터로 받은 특정 HTTP 헤더 값을 조회할 수 있다. 

- 특정 쿠키를 조회하기 위해서도 @GetCookie를 사용할 수 있다.

- 필수 값이면 required=true 옵션을 준다.

 

🚩 그 외에 다양한 옵션은 공식 문서를 확인하자.

Web on Servlet Stack

---

 

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

- 클라이언트 -> 서버로 데이터 전달 시 주로 3가지의 방법을 사용한다.

- 쿼리 파라미터(?) /  HTML Form / HTTP message body

- 앞의 2가지 방법은 둘 다 형식이 같기 때문에 구분없이 조회가 가능하며, 이를 요청 파라미터 조회라고 한다.

@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");
}

 

[hello-form.html] - /resources/static/basic 밑에 두었다.

<!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>

- form을 활용해서 보내주고, HttpServletRequest를 활용해서 파라미터 값을 가져와주었다.

- response를 통해서 write도 해주었다.

- 그러나, 이 방법은 매우 귀찮다. 스프링에서 제공하는 @RequestParam을 사용해보자.

 

 

✔ @RequestMapping / @ResponseBody

@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 메시지 바디에 해당 내용을 직접 입력해준다!

- 파라미터 이름과 변수명이 동일한 경우 파라미터를 생략할 수 있다 (@RequestParam만 써도 됨)

- 또한, String, Integer 같은 단순 타입이면 @RequestParam도 생략 가능하다! (그래도 웬만하면 써주자)

    - 이 경우, required=false 옵션이 적용된다. 파라미터가 필수적으로 들어가야 한다면 required=true 옵션을 지정해주자.

 

 

🚩여러 가지 경우

/request-param

: 파라미터가 없기 때문에 400 발생.

 

/request-param?username=

: 이 경우 빈 문자가 있다고 인식하고 통과

 

- primitive 타입은 null을 입력할 수 없기 때문에 (500 예외) reference 타입으로 바꾸거나, defaultValue 사용해주기.

- defaultValue의 경우 파라미터에 값이 없을 경우 기본 값으로 적용해줄 수 있다.

    - 빈 문자의 경우에도 defaultValue가 적용된다.

    - required 옵션은 의미가 없어진다.

 

 

✔ @RequestParam - Map으로 받기

@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";
}

- 파라미터를 Map 형식으로도 받을 수 있다.

- 파라미터의 값이 여러 개면 MultiValueMap을 사용해서 받을 수 있다.

---

 

| HTTP 요청 파라미터 - @ModelAttribute

- 보통 개발을 진행하면 파라미터를 받아서 필요한 객체를 만들고,

그 객체에 값을 넣어주는 작업을 진행할 텐데 스프링에서는 이를 자동화한다.

[HelloData.java] - 이전에 사용하였던 HelloData이다.

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

@ResponseBody
@RequestMapping("/model-attribute-v1")
public String modelAttributeV1(@ModelAttribute HelloData helloData) {
    log.info("username={}, age={}", helloData.getUsername(),
    helloData.getAge());
    return "ok";
}

- @ModelAttribute HelloData helloData

1. HelloData 객체를 생성한다.

2. 요청 파라미터의 이름으로 HelloData 객체의 프로퍼티를 찾는다. 여기서는 username, age를 찾게 되는 것.

3. 이후, 해당 프로퍼티의 Setter를 찾아서 파라미터의 값을 바인딩한다. (setUsername(), setAge())

 

- 물론, ModelAttribute 역시 생략이 가능하다.

⭐ 기본적으로 String, int, Integer 같은 타입은 @RequestParam으로, 그 외는 @ModelAttribute로 지정된다.

cf) ArgumentResolver로 지정되어 있는 애들은 제외!

 

🚩 @RequestParam vs @ModelAttribute

- @RequestParam은 요청 파라미터를 받아주는 어노테이션,

@ModelAttribute는 요청 파라미터를 받아서 특정 객체에 해당 값을 setter를 통해 바인딩 후 Model 객체에 담아주는 어노테이션.

- 그렇기 때문에, @RequestParam의경우 객체 생성 및 바인딩 작업은 직접해야 하지만,

@ModelAttribute는 객체 생성 및 바인딩, Model에 담아주는 작업까지 자동으로 진행해준다!

---

 

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

- Http message body에 데이터를 담아서 요청할 경우, 어떻게 처리해야 할까?

@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");
}

- 단순히 Http 메시지 바디의 데이터를 inputStream을 활용해서 읽는 부분이다.

- 바이트 코드이기 때문에 인코딩 타입도 지정해줘야 한다.

 

 

✔ InputStream, OutputStream 사용하기

@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");
}

- 조금 더 간단하게 InputStream, OutputStream을 파라미터로 사용할 수 있다.

- InputStream은 HTTP 요청 메시지 바디의 내용을 직접 조회할 수 있으며, OutputStream은 응답 메시지의 바디에 결과를 출력할 수 있다.

- 여기서는 위와 동일하게 맞춰주기 위해, HTTP 요청 메시지 바디의 내용을 인코딩 해서 적어주었다.

 

 

✔ HttpEntity - RequestEntity / ResponseEntity 

@PostMapping("/request-body-string-v3")
public HttpEntity<String> requestBodyStringV3(HttpEntity<String> httpEntity) {
    String messageBody = httpEntity.getBody();
    log.info("messageBody={}", messageBody);
    return new HttpEntity<>("ok");
}

- 혹은 Http header와 body의 정보를 조회하기 위해 HttpEntity를 사용할 수 있다.

- 메시지 바디의 정보를 직접 조회하는 것이며, 요청 파라미터 조회 기능과는 관련이 없다.

    - .getBody()를 통해 얻어올 수 있다.

    - .getHeader()를 통해서 헤더 정보도 조회할 수 있다.

- HttpEntity의 파라미터로 메시지 바디 정보를 입력하여 반환할 수 있다.

- 혹은 RequestEntity와 ResponseEntity를 사용해도 된다. (HttpEntity를 상속받음)

    - RequestEntity<String> httpEntity / return new ResponseEntity<>("ok")

    - RequestEntity의 경우 HttpMethod나 url 정보를 추가할 수 있으며, ResponseEntity는 HTTP 상태 코드를 설정할 수 있다.

 

 

✔ @RequestBody / @ResponseBody

@ResponseBody
@PostMapping("/request-body-string-v4")
public String requestBodyStringV4(@RequestBody String messageBody) {
    log.info("messageBody={}", messageBody);
    return "ok";
}

- 어노테이션을 활용해서도 조회할 수 있다.

- @RequestBody를 사용하여 메시지 바디 정보를 직접 조회할 수 있으며, @ResponseBody를 통해 바디 정보를 직접 반환할 수 있다.

- 단, 헤더 정보의 경우 HttpEntity를 사용하거나 @RequestHeader를 사용해야 한다.

 

🚩⭐ 요청 파라미터 조회: @RequestParam. @ModelAttribute

Http 메시지 바디 직접 조회: @RequestBody

 

---

| HTTP 요청 메시지 - JSON

[RequestBodyJsonController.java]

@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 data = objectMapper.readValue(messageBody, HelloData.class);
        log.info("username={}, age={}", data.getUsername(), data.getAge());
        response.getWriter().write("ok");
    }
}

- 기본적인 방식인 servletRequest를 통해 메시지 바디에서 직접 읽어왔다.

- 이후, objectMapper의 readValue()를 활용하여 자바 객체로 읽어온 메시지바디를 변환시켰다.

 

 

✔ RequestBody / ResponseBody 이용하기

@ResponseBody
@PostMapping("/request-body-json-v2")
public String requestBodyJsonV2(@RequestBody String messageBody) throws
        IOException {
    HelloData data = objectMapper.readValue(messageBody, HelloData.class);
    log.info("username={}, age={}", data.getUsername(), data.getAge());
    return "ok";
}

- 간단하게 @requestBody를 통해서 메시지 바디의 내용을 꺼내올 수 있다.

- 하지만, 이 방식도 문자를 받아서 다시 json으로 변환하는 과정을 거쳐야 한다.

 

 

✔ @RequestBody에 바로 객체 지정하기

@ResponseBody
@PostMapping("/request-body-json-v3")
public String requestBodyJsonV3(@RequestBody HelloData data) {
    log.info("username={}, age={}", data.getUsername(), data.getAge());
    return "ok";
}

- 이렇게 바로 HelloData를 지정할 수 있다!

- 이런 식으로 HttpEntity나 @RequestBody를 사용하면, HTTP 메시지 컨버터가 HTTP 메시지 바디의 내용을 원하는 문자나 객체 등으로 변환해준다.   

- JSON 역시 변환을 해준다!    

- ⭐ 참고로, @RequestBody의 경우 생략이 불가능하다.   

- 생략해버리면 자동으로 @ModelAttribute가 적용되기 때문에, 요청 파라미터를 처리하게 된다.

 

 

✔ HttpEntity 사용하기

@ResponseBody
@PostMapping("/request-body-json-v4")
public String requestBodyJsonV4(HttpEntity<HelloData> httpEntity) {
    HelloData data = httpEntity.getBody();
    log.info("username={}, age={}", data.getUsername(), data.getAge());
    return "ok";
}

- 물론, 이런 식으로 httpEntity를 이용해도 잘 동작한다.

 

 

✔ ResponseBody 응용하기

@ResponseBody
@PostMapping("/request-body-json-v5")
public HelloData requestBodyJsonV5(@RequestBody HelloData data) {
    log.info("username={}, age={}", data.getUsername(), data.getAge());
    return data;
}

- @ResponseBody를 사용하면 해당 객체를 HTTP 메시지 바디에 넣어줄 수 있다. (물론 HttpEntity도 가능)

 

🚩 @RequestBody : JSON 요청 -> Http 메시지 컨버터 -> 객체

@ResponseBody : 객체 -> Http 메시지 컨버터 -> JSON 응답

 

---

| HTTP 응답 - 정적 리소스, 뷰 템플릿, HTTP 메시지

- 스프링에서 응답 데이터를 만드는 방법은 크게 3가지로 나뉜다.

1) 정적 리소스

- 웹 브라우저에 정적인 HTML, css, js 제공 시 사용

2) 뷰 템플릿

- 웹 브라우저에 동적인 HTML 제공 시 사용

3) HTTP 메시지 

- HTTP API 제공 시 HTTP 메시지 바디에 JSON 형식으로 데이터 보내기

 

 

✔ 정적 리소스

- 스프링 부트에서 제공하는 정적 리소스 위치 경로

- 시작 위치: src/main/resources

- 하위 경로는 다음과 같다.

/static, /public, /resources, /META-INF/resources

 

즉, src/main/resources/static/basic/hello-form.html이라는 파일이 있다면,

웹 브라우저에서는 localhost:8080/basic/hello-form.html으로 실행된다.

- 정적 리소스는 해당 파일에 대한 별다른 변경 없이 그대로 서비스된다.

 

 

✔ 뷰 템플릿

- 뷰 템플릿을 거쳐 HTML이 생성되고, 뷰가 응답을 만들어서 전달한다.

- 기본 경로는 다음과 같다. (나중에 프로퍼티 파일에서 classpath 변경해주면 된다)

src/main/resources/templates

 

[hello.html] - /response/hello.html

<!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>

- model에서 'data'라는 key를 가지는 값을 꺼내서 empty 부분에 넣어준다.

 

[ResponseViewController.java]

@Controller
public class ResponseViewController {

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

    @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!");
    }
}

- 위의 3가지 방법으로 뷰를 동적으로 변환할 수 있다.

    - 첫 번째 방법은 ModelAndView를 통해서 데이터를 넣어주고 뷰 이름을 설정해주는 방법,

    - 두 번째 방법은 모델에 데이터 넣어주고 String형으로 뷰의 논리 이름을 반환하는 방법,

        - 단, 이 경우는 @ResponseBody가 없어야 한다. 있으면 그대로 response/hello가 화면에 찍힘!

    - 3번은 권장하지는 않지만, 모델에 데이터를 넣어주고 void로 반환하는 방법.

        - @Controller가 붙어 있고 HttpServletResponse, outputStream 같은 HTTP 메시지 바디 처리 파라미터가 없으면, 

       @RequestMapping에 붙어 있는 URL을 참고해서 논리 뷰 이름으로 사용하게 된다. 단, 이 방법은 권장하지 않는다.

 

 

✔ HTTP API, 메시지 바디에 직접 입력

- HTTP 메시지 바디에 JSON과 같은 형식으로 데이터를 실어 보낸다.

- 정적 리소스, 뷰 템플릿을 사용해도 HTTP 응답 메시지 바디에 HTML 데이터가 담기지만, 이를 거치지 않고 바로 전달하는 경우이다.

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

@GetMapping("/response-body-string-v2")
public ResponseEntity<String> responseBodyV2() {
    return new ResponseEntity<>("ok", HttpStatus.OK);
}

@GetMapping("/response-body-string-v3")
@ResponseBody
public String responseBodyV3() {
    return "ok";
}

@GetMapping("/response-body-json-v1")
public ResponseEntity<HelloData> responseBodyJsonV1() {
    HelloData helloData = new HelloData();
    helloData.setUsername("hi");
    helloData.setAge(20);
    return new ResponseEntity<>(helloData, HttpStatus.OK);
}

@GetMapping("/response-body-json-v2")
@ResponseBody
@ResponseStatus(HttpStatus.OK)
public HelloData responseBodyJsonV2() {
    HelloData helloData = new HelloData();
    helloData.setUsername("hihi");
    helloData.setAge(22);
    return helloData;
}

- 모두 다 페이지에 잘 찍히는 걸 볼 수 있다.

1) HttpServletResponse를 이용해서 메시지 바디에 직접 메시지 전달하기

2) ResponseEntity를 활용해서 Http 메시지 바디 정보 넣기 + 응답 코드 설정

3) @ResponseBody를 사용하기

4) ResponseEntity 반환 - 이때 객체를 넣으면 JSON 형식으로 변환되어서 반환된다.

5) @ResponseBody + @ResponseStatus 사용 - 객체 반환 및 응답 코드를 설정해준다.

 

🚩 @RestController = @Controller + @ResponseBody 

- HTTP 메시지 바디에 직접 데이터를 입력하는 방법으로, Rest API를 만들 때 사용하는 컨트롤러.

 

🚩 ResponseEntity는 Http header를 조금 더 편리하게 변경 가능, 상태 코드를 변경해야 할 때 사용하면 좋을 것 같다. 그외의 기능은 거의 동일하기 때문에... 상태 코드를 변환하는 게 아니라면 그냥 @ResponseBody를 사용해도 좋을 듯.

- 근데 보통 CSR의 경우 (리액트나 그런 거 사용) 5번 방법을 가장 많이 사용하는 것 같다! (@RestController 이용) 나도 그렇고...!

---

 

| HTTP 메시지 컨버터

- HTTP API처럼 JSON 데이터를 HTTP 메시지 바디에서 직접 읽거나 쓸 때, HTTP 메시지 컨버터를 이용한다.

- @ResponseBody를 사용하면 viewResolver 대신에 HttpMessageConverter가 동작한다.

    - 이때, 기본적인 문자는 StringHttpMessageConverter, 객체는 MappingJackson2HttpMessageConverter가 동작.

 

- 스프링은 다음의 경우에 HTTP 메시지 컨버터를 사용한다.

HTTP 요청 -> @RequestBody, HttpEntity / RequestEntityHTTP 응답 -> @ResponseBody, HttpEntity / ResponseEntity

 

[HttpMessageConverter.java]

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;

}

- 우선, canRead()와 canWrite()를 통해서 읽고 쓸 수 있는 여부를 확인한다. (해당 클래스, 미디어 타입을 지원하는지)

- getSupportedMediaTypes는 지원하는 미디어 타입에 대한 리스트를 리턴하는 것.

- read, write는 메시지 컨버터를 통해 실제로 읽고 쓰는 동작을 수행하는 함수이다.

 

🚩 Http 요청이 들어왔을 때

- 만약 컨트롤러에서 @RequestBody or HttpEntity를 파라미터로 사용하고 있다.

- canRead()를 호출하여 대상 클래스 타입(Object 타입)을 지원하는지 확인한다.

- Http 요청의 Content-type을 확인하여 해당 미디어 타입을 지원하는지 확인.

- 통과했다면 read()를 통해서 객체 생성 및 반환 작업 진행

 

🚩 Http 응답을 생성할 때

- 컨트롤러에서 @ResponseBody나 HttpEntity로 값이 반환된다.

- canWrite()를 호출하여 메시지를 쓸 수 있는지 확인한다.

- 대상 클래스 타입을 지원하는지 확인한다.

- Http 요청의 Accept을 확인하여 해당 미디어 타입을 지원하는지 확인. (혹은 @RequestMapping의 produces 부분 확인)

- 통과했다면 write()를 통해서 HTTP 응답 메시지 바디에 데이터 생성

 

 

✔ 스프링에서 제공하는 메시지 컨버터

- ByteArrayHttpMessageConverter

: Object 타입은 byte[]만, 미디어타입은 모든 것을 지원한다.

ex) @RequestBody byte[] paramter -> 모든 요청을 바이트 배열로 받을 수 있다!

: 대표적으로 파일 업로드 같은 예시를 생각해보면 좋을 것 같다.

: 응답 시에는 미디어타입이 application/octet-stream으로 설정된다.

 

- StringHttpMessageConverter

: Object 타입은 String, 미디어타입은 모든 것을 지원한다.

: Http 본문을 String으로 가져오거나(@RequestBody String param), 리턴 값으로 사용하면 문자열을 전달해준다. 

: 이때 content-type은 text/plain이 된다.

content-type: application/json

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

 

- FormHttpMessageConverter

: Object 타입은 MultiValueMap<String, String>이고, 미디어타입은 application/x-www-form-urlencoded만 지원한다.

: Form-data를 주고받을 때 사용하지만, 보통 이 경우에는 @ModelAttribute를 사용하게 된다.

 

- ⭐ MappingJackson2HttpMessageConverter

: Jackson의 ObjectMapper를 활용해서 Json과 오브젝트 사이의 변환을 지원해준다. 미디어타입은 application/json을 지원한다.

: Object 타입으로 객체나 HashMap을 사용한다.

content-type: application/json

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

---

 

| HTTP 메시지 컨버터는 어디에서 사용되는 걸까?

- 바로, @RequestMapping을 처리하는 핸들러 어댑터인 RequestMappingHandlerAdapter에 있다.

 

우선, 당장 우리가 작성한 컨트롤러를 보자. @RequestBody, HttpEntity, InputStream, Model 등 다양한 파라미터가 존재한다.

-> 이들을 바로 'ArgumentResolver'가 처리해준다!

 

🚩 RequestMappingHandlerAdapter는 ArgumentResolver를 호출해서 컨트롤러가 필요로 하는 다양한 파라미터 값을 생성한다.

- 스프링에서 제공하는 ArgumentResolver는 매우 많다. (정확한 이름은 HandlerMethodArgumentResolver)

 

[HandlerMethodArgumentResolver.java]

public interface HandlerMethodArgumentResolver {
    boolean supportsParameter(MethodParameter parameter);

    @Nullable
    Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
                           NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception;

}

- supportsParameter를 통해 해당 파라미터를 지원하는지, resolveArgument를 통해 객체를 만들어서 넘겨주는 것이다!

- 대충 뭐 이런 식으로 되게 많다는 것...!

- 아무튼, 해당 파라미터 형식(어노테이션)을 처리해주는 ArgumentResolver들이 굉장히 많이 존재한다고 보면 된다!

- 물론, 우리가 커스텀해서 원하는 ArgumentResolver도 만들수 있다.

 

🚩마찬가지로, 컨트롤러의 응답값도 처리해주는 Handler가 존재한다.

- HandlerMethodReturnValueHandler, 줄여서 ReturnValueHandler라고 한다.

 

[HandlerMethodReturnValueHandler.java]

public interface HandlerMethodReturnValueHandler {
    boolean supportsReturnType(MethodParameter returnType);

    void handleReturnValue(@Nullable Object returnValue, MethodParameter returnType,
                           ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception;

}

- 마찬가지로 리턴타입을 지원하는지 확인하고, 지원한다면 원하는 데이터 포맷으로 변경해준다.

- 여기서 파라미터 값으로 들어가는 returnValue, 모델과 뷰를 처리하는 mavContainer, 그리고 webRequest를 통해 값을 반환한다.

- 마찬가지로 커스텀이 가능한데, 커스텀 시에 webRequest.getNativeResponse(HttpServletResponse.class)를 활용하여 HttpServletResponse로 반환해서 HTTP 메시지 바디에 값을 적는다든지... 그런 기능을 할 수 있다.

 

 

✔ 그래서, HTTP 메시지 컨버터는 어디 있는데?

- HttpMessageConverter는 ArgumentResolver가 사용한다!

 

 

🚩 HTTP 요청이 들어왔을 때

- @RequestBody를 처리하는 ArgumentResolver가 있고(RequestResponseBodyMethodProcessor),

HttpEntity를 처리하는 ArgumentResolver가 있을 것이다(HttpEntityMethodProcessor).

그리고, 이러한 ArgumentResolver들은 HTTP 메시지 컨버터를 사용해서 필요한 객체를 생성한다!

 

[RequestResponseBodyMethodProcessor.java]

@Override
public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
                              NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {

    parameter = parameter.nestedIfOptional();

    ///////// HERE! /////////////
    Object arg = readWithMessageConverters(webRequest, parameter, parameter.getNestedGenericParameterType());
    String name = Conventions.getVariableNameForParameter(parameter);

    if (binderFactory != null) {
        WebDataBinder binder = binderFactory.createBinder(webRequest, arg, name);
        if (arg != null) {
            validateIfApplicable(binder, parameter);
            if (binder.getBindingResult().hasErrors() && isBindExceptionRequired(binder, parameter)) {
                throw new MethodArgumentNotValidException(parameter, binder.getBindingResult());
            }
        }
        if (mavContainer != null) {
            mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());
        }
    }

    return adaptArgumentIfNecessary(arg, parameter);
}

- 코드에서 Here이라고 되어 있는 부분에서 보면 readWithMessageConverters를 사용하는 걸 볼 수 있다!

- 여기서 리턴 값으로 Object를 주면서 어떠한 객체를 생성한다고 볼 수 있다.

 

- HandlerMethodArgumentResolver를 구현한 AbstractHttpMessageConverter를 보자.

@Nullable
protected <T> Object readWithMessageConverters(HttpInputMessage inputMessage, MethodParameter parameter,
                                               Type targetType) throws IOException, HttpMediaTypeNotSupportedException, HttpMessageNotReadableException {

    ...

    Class<?> contextClass = parameter.getContainingClass();
    Class<T> targetClass = (targetType instanceof Class ? (Class<T>) targetType : null);
    if (targetClass == null) {
        ResolvableType resolvableType = ResolvableType.forMethodParameter(parameter);
        targetClass = (Class<T>) resolvableType.resolve();
    }

    HttpMethod httpMethod = (inputMessage instanceof HttpRequest ? ((HttpRequest) inputMessage).getMethod() : null);
    Object body = NO_VALUE;

    EmptyBodyCheckingHttpInputMessage message = null;
    try {
        message = new EmptyBodyCheckingHttpInputMessage(inputMessage);

        /////// #### HERE!
        for (HttpMessageConverter<?> converter : this.messageConverters) {
            Class<HttpMessageConverter<?>> converterType = (Class<HttpMessageConverter<?>>) converter.getClass();
            GenericHttpMessageConverter<?> genericConverter =
                    (converter instanceof GenericHttpMessageConverter ? (GenericHttpMessageConverter<?>) converter : null);
            if (genericConverter != null ? genericConverter.canRead(targetType, contextClass, contentType) :
                    //// #### HERE! - canRead()
                    (targetClass != null && converter.canRead(targetClass, contentType))) {
                if (message.hasBody()) {
                    //// #### HERE! - read()
                    HttpInputMessage msgToUse =
                            getAdvice().beforeBodyRead(message, parameter, targetType, converterType);
                    body = (genericConverter != null ? genericConverter.read(targetType, contextClass, msgToUse) :
                            ((HttpMessageConverter<T>) converter).read(targetClass, msgToUse));
                    body = getAdvice().afterBodyRead(body, msgToUse, parameter, targetType, converterType);
                }
                else {
                    body = getAdvice().handleEmptyBody(null, message, parameter, targetType, converterType);
                }
                break;
            }
        }
    }
    ...

 - 코드가 길어서 복잡하지만, 중간에 for문을 통해 메시지 컨버터 반복문을 돌면서 canRead()를 통해 체크하고, 처리 가능하면 read로 만들어내는 식이다. 즉, 결국 argumentResolver들이 http 메시지 컨버터를 사용해서 필요한 객체를 생성해준다고 볼 수 있다!

 

 

🚩 HTTP 응답 생성할 때

- @ResponseBody와 HttpEntity를 처리하는 ReturnValueResolver가 있다. (요청 때랑 둘 다 동일함)

 

[RequestResponseBodyMethodProcessor.java]

@Override
public void handleReturnValue(@Nullable Object returnValue, MethodParameter returnType,
                              ModelAndViewContainer mavContainer, NativeWebRequest webRequest)
        throws IOException, HttpMediaTypeNotAcceptableException, HttpMessageNotWritableException {

    mavContainer.setRequestHandled(true);
    ServletServerHttpRequest inputMessage = createInputMessage(webRequest);
    ServletServerHttpResponse outputMessage = createOutputMessage(webRequest);

    ///// #### HERE!
    writeWithMessageConverters(returnValue, returnType, inputMessage, outputMessage);
}

- 마찬가지로 여기서도 messageConverter를 호출해서 응답 결과를 만들어준다!

 

- HttpMessageConverter를 구현한 클래스도 정말 많다.

 

- 그리고, 스프링은 다음을 모두 인터페이스로 제공하기 때문에 우리가 필요할 때 확장해서 사용하면 된다!

1) HandlerMethodArgumentResolver

2) HandlerMethodReturnValueResolver

3) HttpMessageConverter

 

- 기능을 확장할 때는 WebMvcConfiguer를 상속받아서 스프링 빈으로 등록하면 된다. 

(커스텀 어노테이션을 만들었을 때 addArgumentResolver를 통해 커스텀한 ArgumentResolver 추가 정도는 많이 사용한다!)

 

 

🚩 추가적으로 조금 헷갈려서 적어두는 내용.

dispatcherServlet의 동작 과정에서, 

ModelAndView mv = ha.handle(processedRequest, response, mappedHandler.getHandler())를 통해 ModelAndView를 반환받는 걸 볼 수 있다.그러나, @ResponseBody의 경우 viewResolver 같은 작업이 이루어지지 않기 때문에,

이 경우에는 HttpMessageConverter가 response 객체 내에 응답 메시지를 넣어두고, mv에는 null이 들어가게 된다고 한다.

 

음... 조금 더 찾아봤는데,

핸들러 어댑터가 실행되면서(ha)

-> RequestMappingHandlerAdapter에서 invocableMethod.invokeAndHandle() 호출

-> 핸들러 실행, 반환타입 결정

(메서드 내부)

 

getResponseStatusReason()이 false이기 때문에 결과적으로 mavContainer.setRequestHandled(false); 처리.

returnValue의 경우 returnValueHandler를 사용하는데, 이때 RequestResponseBodyMethodProcessor를 호출한다.

 

여기서 mavContainer.setRequestHandled(true)가 되고, 

return으로 담겨진 메시지를 String 값에 담아서 ServletServerHttpResponse Body에 내용을 기록하게 된다.

-> 이후, RequestMappingHandlerAdapter에서 return getModelAndiew(mavConatiner, modelFactory, webRequest); 실행

 

(메서드 내부)

if (mavContainer.isRequestHandled()) < 이게 true여서 결과적으로 null이 반환된다!

--> 그래서 ModelAndView에 null이 들어가는 거였다...!

 

참고) 더 자세한 내용은 이 분 블로그 글을 보는 게 좋을 것 같다!

[Spring MVC] @ResponseBody 응답에 대하여 알아보자(1)

 

- 아무튼, 이번 포스팅은 코드 좀 까면서 보느라 조금 더 걸린 것 같다.

- 다음 포스팅에서는 진짜 페이지를 만들어보면서 스프링 MVC 1 강의를 끝마치고자 한다!