9 분 소요

HTTP 요청 - 기본, 헤더 조회

애노테이션 기반의 스프링 컨트롤러는 다양한 파리미터를 지원한다. HTTP 헤더 정보를 조회하는 방법을 알아보자.

@Slf4j // 로그를 선언해준다.
@RestController
public class RequestHeaderController {

    @RequestMapping("/headers")
    public String headers(HttpServletRequest req,
                          HttpServletResponse res,
                          HttpMethod httpMethod,
                          Locale locale,
                          @RequestHeader MultiValueMap<String, String> headerMap,
                          @RequestHeader("host") String host,
                          @CookieValue(value="myCookie", required = false) String cookie){

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

        return "ok";
    }
}
  • HttpMethod: HTTP 메서드를 조회한다.
  • Locale: Locale 정보를 조회한다.
  • @RequestHeader MultiValueMap<String, String> headerMap: 모든 HTTP 헤더를 MultiValueMap 형식으로 조회한다.
  • @RequestHeader("host") String host: 특정 HTTP 헤더를 조회한다.
  • @CookieValue(value="myCookie", required = false) String cookie: 특정 쿠키를 조회한다.

MultiValueMap

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

사용 예시

MultiValueMap<String, String> map = new LinkedMultiValueMap();
    map.add("keyA", "value1");
    map.add("keyA", "value2");
    
    List<String> values = map.get("keyA"); //[value1,value2]처럼 배열 형태로 반환

참고
@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

HTTP 요청 데이터 조회

개요

서블릿에서 학습했던 HTTP 요청 데이터를 조회 하는 방법을 다시 떠올려보자. 그리고 서블릿으로 학습했던 내용을 스프링이 얼마나 깔끔하고 효율적으로 바꾸어주는지 알아보자.
HTTP 요청 메시지를 통해 클라이언트에서 서버로 데이터를 전달할 때는 주로 다음 3가지 방법을 사용한다.

1번과 2번 방식은 HttpServletRequestrequest.getParameter()를 사용해 조회할 수 있다. GET 쿼리 파리미터 전송 방식이든, POST HTML Form 전송 방식이든 둘다 형식이 같으므로 구분없이 조회할 수 있다.
이것을 간단히 요청 파라미터(request parameter) 조회라 한다.

3번 방식은 데이터 바디에 직접 오기 때문에 해당 미디어 타입을 처리할 수 있는 HTTP 메시지 컨버터가 실행된다.

  1. GET - 쿼리 파라미터
    • /url?username=hello&age=20
    • 메시지 바디 없이, URL의 쿼리 파라미터에 데이터를 포함해서 전달
    • 예) 검색, 필터, 페이징등에서 많이 사용하는 방식
    • 예시
      http://localhost:8080/request-param?username=hello&age=20
      
  2. POST - HTML Form
    • content-type: application/x-www-form-urlencoded
    • 메시지 바디에 쿼리 파리미터 형식으로 전달 username=hello&age=20
    • 예) 회원 가입, 상품 주문, HTML Form 사용
    • 예시
      POST /request-param ...
      content-type: application/x-www-form-urlencoded
      username=hello&age=20
      
  3. HTTP message body에 데이터를 직접 담아서 요청
    • HTTP API에서 주로 사용, JSON, XML, TEXT
    • 데이터 형식은 주로 JSON 사용
    • POST, PUT, PATCH

하나씩 알아보자.

🌸 HTTP 요청 파라미터 (쿼리 파라미터, HTML Form) 조회 - @RequestParam

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

hello-form.html

테스트용 HTML Form으로 /resources/static 아래에 두면 스프링 부트가 자동으로 인식한다.

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

v1 - HttpServletRequest

RequestParamController

@Slf4j
@Controller
public class RequestParamController {

    @RequestMapping("/request-param-v1")
    public void requestParamV1(HttpServletRequest req, HttpServletResponse res) throws IOException {

        String username = req.getParameter("username");
        int age = Integer.parseInt(req.getParameter("age"));
        log.info("username={}, age={}", username, age);

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

여기서는 단순히 HttpServletRequest가 제공하는 req.getParameter()으로 요청 파라미터를 조회했다.

v2 - @RequestParam

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

@Slf4j
@Controller
public class RequestParamController {

    @ResponseBody // View 조회를 무시하고, HTTP message body에 직접 해당 내용 입력
    @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 message body에 직접 해당 내용 입력

v3 - @RequestParam

RequestParamController

@Slf4j
@Controller
public class RequestParamController {

    @ResponseBody
    @RequestMapping("/request-param-v3")
    public String requestParamV3(
            @RequestParam String username, // 파라미터의 이름과 변수명이 같은 경우 생략 가능
            @RequestParam int age){

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

        return "ok";
    }
}
  • HTTP 파라미터 이름이 변수 이름과 같으면 @RequestParam(name=”xx”) 생략 가능

v4 - @RequestParam

RequestParamController

@Slf4j
@Controller
public class RequestParamController {

    @ResponseBody
    @RequestMapping("/request-param-v4")
    public String requestParamV4(
            String username, // 파라미터의 이름과 변수명이 같은 경우 @RequestParam도 생략 가능
            int age){

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

        return "ok";
    }
}
  • String , int , Integer 등의 단순 타입이면 @RequestParam도 생략 가능

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

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

파라미터 필수 여부 - required

RequestParamController

@Slf4j
@Controller
public class RequestParamController {

    @ResponseBody
    @RequestMapping("/request-param-required")
    public String requestParamRequired(
            @RequestParam(required = true) String username, // 해당 파라미터는 무조건 있어야 한다. (default가 true)
            @RequestParam(required = false) Integer age){ // 해당 파라미터가 없어도 정상적으로 실행된다.

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

        return "ok";
    }
}
  • @RequestParam.required
    - 파리미터 필수 여부
    - 기본값이 파리미터 필수(true)이다.

주의
@RequestParam(required = true) String username일 때, /request-param-required?username=처럼 파라미터 이름만 있고 값이 없는 경우에 username=로 들어온다.
왜냐햐면 ""(빈문자)는 null이 아니기 때문이다.

주의
@RequestParam(required = false) int age는 500 예외가 발생하다.
왜냐하면 int에 null을 넣는 것은 불가능하기 때문이다. 따라서 null을 받을 수 있는 Integer로 변경하거나 defaultValue를 사용한다.

기본 값 적용 - defaultValue

RequestParamController

@Slf4j
@Controller
public class RequestParamController {

    @ResponseBody
    @RequestMapping("/request-param-default")
    public String requestParamDefault(
            @RequestParam(required = true, defaultValue = "guest") String username,
            @RequestParam(required = false, defaultValue = "-1") int age){ // defaultValue를 지정한 경우 int 자료형을 사용할 수 있다.

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

        return "ok";
    }
}
  • 파라미터에 값이 없는 경우 defaultValue 를 사용하면 기본 값을 적용할 수 있다.
  • 이미 기본 값이 있기 때문에 required 는 의미가 없다.

주의
defaultValue 는 빈 문자의 경우에도 설정한 기본 값이 적용된다.

  • @RequestParam(defaultValue = "guest") String username일 때, /request-param-required?username=처럼 파라미터 이름만 있고 값이 없는 경우에 username=guest로 들어온다.

모든 파라미터 조회 - Map

RequestParamController

@Slf4j
@Controller
public class RequestParamController {

    @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으로 조회할 수 있다.

  • @RequestParam Map
    - Map(key=value)
  • @RequestParam MultiValueMap
    - MultiValueMap(key=[value1, value2, …]
    - ex) ?userIds=id1&userIds=id2 => (key=userIds, value=[id1, id2])

파라미터의 값이 1개가 확실하다면 Map을 사용해도 되지만, 그렇지 않다면 MultiValueMap을 사용하자.
(보통의 경우 파라미터 값은 1개를 사용한다.)

🌸 HTTP 요청 파라미터 (쿼리 파라미터, HTML Form) 조회 - @ModelAttribute

HelloData

import lombok.Data;

@Data // 롬복에서 제공하는 애노테이션이다.
public class HelloData {

    private String username;
    private int age;
}

lombok - @Data

  • @Getter , @Setter , @ToString , @EqualsAndHashCode , @RequiredArgsConstructor를 자동으로 적용해준다.

v1 - @ModelAttribute 적용

RequestParamController

@Slf4j
@Controller
public class RequestParamController {

    @ResponseBody
    @RequestMapping("/model-attribute-v1")
    public String modelAttributeV1(@ModelAttribute HelloData helloData){

        log.info("username={}, age={}", helloData.getUsername(), helloData.getAge());
        log.info("helloData={}", helloData); // toString을 자동으로 만들어준다.

        return "ok";
    }
}

마치 마법처럼 HelloData 객체가 생성되고, 요청 파라미터의 값도 모두 들어가 있다.
스프링 MVC는 @ModelAttribute가 있으면 다음을 실행한다.

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

프로퍼티

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

참고
@RequestParam을 이용한다면 아래처럼 직접 객체를 생성한 뒤에 파라미터 값을 넣었을 것이다.

@Slf4j
@Controller
public class RequestParamController {

    @ResponseBody
    @RequestMapping("/model-attribute-v1")
    public String modelAttributeV1(@RequestParam String username, @RequestParam int age){

        HelloData helloData = new HelloData();
        helloData.setUsername(username);
        helloData.setAge(age);

        log.info("username={}, age={}", helloData.getUsername(), helloData.getAge());
        log.info("helloData={}", helloData); 

        return "ok";
    }
}

v2 - @ModelAttribute 생략

RequestParamController

@Slf4j
@Controller
public class RequestParamController {

    @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로 지정해둔 타입 외)

참고
argument resolver는 뒤에서 학습한다.

🌸 HTTP 요청 메시지 (message body) 조회 - 단순 텍스트

요청 파라미터와 다르게, HTTP 메시지 바디를 통해 데이터가 직접 넘어오는 경우는 @RequestParam, @ModelAttribute를 사용할 수 없다. (물론 HTML Form 형식으로 전달되는 경우는 요청 파라미터로 인정된다.)
먼저 가장 단순한 텍스트 메시지를 HTTP 메시지 바디에 담아서 전송하고, 읽어보자.

v1 - ServletInputStream

RequestBodyStringController

@Slf4j
@Controller
public class RequestBodyStringController {

    @PostMapping("/request-body-string-v1")
    public void requestBodyString(HttpServletRequest req, HttpServletResponse res) throws IOException {

        ServletInputStream inputStream = req.getInputStream();
        String meessageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8);

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

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

HTTP 메시지 바디의 데이터를 InputStram을 사용해서 직접 읽을 수 있다.

v2 - InputStream, Writer

RequestBodyStringController

@Slf4j
@Controller
public class RequestBodyStringController {

    @PostMapping("/request-body-string-v2")
    public void requestBodyStringV2(InputStream inputStream, Writer responseWriter) throws IOException {

        String meessageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8);

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

        responseWriter.write("ok");
    }
}

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

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

v3 - HttpEntity

RequestBodyStringController

@Slf4j
@Controller
public class RequestBodyStringController {

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

        String messageBody = httpEntity.getBody();

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

        return new HttpEntity<>("ok"); // 응답에도 사용 가능하다.
    }
}

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

  • HttpEntity: HTTP header, body 정보를 편리하게 조회
    - 메시지 바디 정보를 직접 조회
    - 요청 파라미터를 조회하는 기능과 관계 없음 @RequestParam X, @ModelAttribute X
  • HttpEntity는 응답에도 사용 가능
    - 메시지 바디 정보 직접 반환
    - 헤더 정보 포함 가능
    - view 조회X


참고
HttpEntity를 상속받은 다음 객체들도 같은 기능을 제공한다.

  • RequestEntity: HttpMethod, url 정보가 추가, 요청에서 사용
  • ResponseEntity: HTTP 상태 코드 설정 가능, 응답에서 사용
@Slf4j
@Controller
public class RequestBodyStringController {

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

        String messageBody = httpEntity.getBody();

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

        return new ResponseEntity<String>("ok", HttpStatus.CREATED); // 상태코드를 반환할 수 있다.
    }
}

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

v4 - @RequestBody, @ResponseBody 🌟

RequestBodyStringController

@Slf4j
@Controller
public class RequestBodyStringController {

    @ResponseBody
    @PostMapping("/request-body-string-v4")
    public String requestBodyStringV4(@RequestBody String messageBody) throws IOException {

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

        return "ok";
    }
}

실무에서 정말 많이 사용하는 방식이다.

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

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

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

  • 요청 파라미터를 조회하는 기능: @RequestParam, @ModelAttribute
  • HTTP 메시지 바디를 직접 조회하는 기능: @RequestBody

🌸 [스프링] HTTP 요청 메시지 (message body) 조회 - JSON

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

v1 - HttpServletRequest

RequestBodyJsonController

@Slf4j
@Controller
public class RequestBodyJsonController {

    private ObjectMapper objectMapper = new ObjectMapper();

    @PostMapping("/request-body-json-v1")
    public void requestBodyJsonV1(HttpServletRequest req, HttpServletResponse res) throws IOException {

        ServletInputStream inputStream = req.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());

        res.getWriter().write("ok");
    }
}
  • HttpServletRequest를 사용해서 직접 HTTP 메시지 바디에서 데이터를 읽어와서, 문자로 변환한다.
  • 문자로 된 JSON 데이터를 Jackson 라이브러리인 objectMapper를 사용해서 자바 객체로 변환한다.

v2 - @RequestBody 문자 변환

RequestBodyJsonController

@Slf4j
@Controller
public class RequestBodyJsonController {

    private ObjectMapper objectMapper = new ObjectMapper();

    @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 데이터인 messageBodyobjectMapper를 통해서 자바 객체로 변환한다.
  • 문자로 변환하고 다시 json으로 변환하는 과정이 불편하다. @ModelAttribute처럼 한번에 객체로 변환할 수는 없을까?

v3 - @RequestBody 객체 변환

RequestBodyJsonController

@Slf4j
@Controller
public class RequestBodyJsonController {

    @ResponseBody
    @PostMapping("/request-body-json-v3")
    public String requestBodyJsonV3(@RequestBody HelloData data) {

        log.info("username={}, age={}", data.getUsername(), data.getAge());

        return "ok";
    }
}
  • @RequestBody 객체 파라미터
    - @RequestBody HelloData data
    - @RequestBody에 직접 만든 객체를 지정할 수 있다.

@RequestBody는 생략 불가능

@ModelAttribute에서 학습한 내용을 떠올려보자.
스프링은 @ModelAttribute, @RequestParam과 같은 해당 애노테이션을 생략시 다음과 같은 규칙을 적용한다.

  • String, int, Integer 같은 단순 타입 -> @RequestParam이 자동으로 적용된다.
  • 나머지 -> @ModelAttribute이 자동으로 적용된다. (argument resolver 로 지정해둔 타입 외)

따라서 이 경우 HelloData에 @RequestBody를 생략하면 @ModelAttribute가 적용되어버린다.
HelloData data -> @ModelAttribute HelloData data
따라서 생략하면 HTTP 메시지 바디가 아니라 요청 파라미터를 처리하게 된다.

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

v4 - HttpEntity

RequestBodyJsonController

@Slf4j
@Controller
public class RequestBodyJsonController {

    @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를 사용해도 된다.

v5 - @RequestBody 객체를 메시지 바디에 직접 넣기

RequestBodyJsonController

@Slf4j
@Controller
public class RequestBodyJsonController {

    @ResponseBody
    @PostMapping("/request-body-json-v5")
    public HelloData requestBodyJsonV5(@RequestBody HelloData data) { // 리턴 타입이 HelloData 객체!

        log.info("username={}, age={}", data.getUsername(), data.getAge());

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

  • v5 정리
    @RequestBody 요청
    - JSON 요청 -> HTTP 메시지 컨버터 -> 객체
    @ResponseBody 응답
    - 객체 -> HTTP 메시지 컨버터 -> JSON 응답



💛 개인 공부 기록용 블로그입니다. 👻

맨 위로 이동하기