[스프링 MVC] 기본 기능

스프링 MVC 1편의 강의 내용을 정리한 포스팅입니다.

---

요청 매핑

매핑 정보

클래스에 @Controller를 추가할 경우 반환 값이 String이면 뷰 이름으로 인식되는 반면, @RestController의 경우 뷰 이름이 아닌 해당 문자열을 HTTP 바디에 바로 입력하게 된다.

더불어 @RequestMapping을 이용함으로써 특정 URL과 매핑이 가능한데, 여러 개의 URL을 배열로 등록함으로써 다중 설정도 가능하다.

 

HTTP 메서드

@RequestMapping에 메서드 속성을 추가하지 않으면 메서드에 관계없이 호출되지만, @RequestMapping(value = "/mapping-get", method = RequestMethod.GET)와 같이 속성을 지정할 경우 메서드가 일치하지 않을 때 405 상태코드를 반환한다.

@RequestMapping에 메서드 속성을 지정하는 대신 @GetMapping, @PostMapping과 같이 메서드 종류에 따른 애노테이션을 이용할 수도 있다.

 

Path Variable

리소스 경로에 식별자를 넣을 수 있는 기능을 가지고 있으며, 다중 사용도 가능하다.

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

 

특정 파라미터 / 헤더 조건 매핑

특정 파라미터 또는 헤더가 있거나 없는 조건을 추가할 수 있다.

@GetMapping(value = "/mapping-param", params = "mode=debug") //URL에 파라미터 추가해야 매핑됨.
public String mappingParam() {
    return "ok";
}

@GetMapping(value = "/mapping-header", headers = "mode=debug") //HTTP 헤더에 추가해야 매핑됨.
public String mappingHeader() {
    return "ok";
}

 

미디어 타입 조건 매핑 - HTTP 요청 Content-type, consumes / Accept, produces

consumes 값은 HTTP 요청의 Content-Type 헤더를 기반으로 매핑하며 일치하지 않으면 415 상태코드를 반환하고,

produces 값은 HTTP 요청의 Accept 헤더를 기반으로 매핑하며 일치하지 않으면 406 상태코드를 반환한다.

 

 

 

HTTP 요청 파라미터(1) - 헤더 정보 조회

@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); //HTTP 메서드 조회
        log.info("locale={}", locale); //Locale 정보 조회
        log.info("headerMap={}", headerMap); //모든 HTTP 헤더를 MultiValueMap 형식으로 조회(하나의 키에 여러 값을 받을 수 O)
        log.info("header host={}", host); //특정 HTTP 헤더 조회
        log.info("myCookie={}", cookie); //value 값에 따른 특정 쿠키 조회
        return "ok";
    }
}

 

 

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

GET 방식의 쿼리 파라미터 조회와 POST 방식의 HTML Form 전송 방식은 공통적인 요청 형식을 가지고 있다. 따라서 구분 없이 조회가 가능한데, 해당 조회 방식을 요청 파라미터 조회라고 한다. 스프링을 이용해 요청 파라미터를 조회할 수 있는 방법은 다음과 같다.

1. HttpServletRequest의 getParameter()

2. @RequestParam

@ResponseBody
@RequestMapping("/request-param")
public String requestParam(
        @RequestParam("username") String username, 
        @RequestParam("age") int age) {
    log.info("username={}, age={}",username,age);
    return "ok";
}

해당 애노테이션을 이용하면 파라미터 이름을 통한 바인딩이 가능하다.

2-1. HTTP 파라미터 이름과 변수 이름이 같다면 애노테이션 내 name 속성을 생략할 수 있다.

2-2. required 속성을 통해 파라미터 필수 여부 또한 지정할 수 있는데 주의해야 할 점이 있다. int와 같은 기본형(primitive) 타입의 경우 null을 받을 수 없기 때문에 속성 값을 false로 지정할 경우 null을 받을 수 있는 참조형(reference) 타입으로 선언하거나, @RequestParam(required = false, defaultValue = "-1") int age와 같이 defaultValue 속성을 이용해 값이 들어오지 않았을 때 기본으로 넣어줄 값을 지정해주어야 한다. 해당 속성은 빈 문자가 들어온 경우에도 적용된다.

2-3. @RequestParam Map<String, Object> paramMap과 같이 파라미터를 Map, MultiValueMap으로 조회할 수 있다.

 

3. @ModelAttribute

요청 파라미터의 값으로 객체를 생성하기 위해서는 @RequestParam으로 각자의 값을 받고 객체를 생성한 뒤 값을 할당해주어야 할 것이다. 하지만 해당 애노테이션을 이용하면 이 과정을 거치지 않고도 값을 객체로 받을 수 있다. 따라서 다음 코드도 정상적으로 동작한다.

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

3-1. 스프링 MVC는 위의 코드를 다음과 같은 과정을 거쳐 실행한다.
우선 HelloData 객체를 생성하고, 요청 파라미터의 이름으로 객체 내 멤버 변수를 찾아 setter를 호출해 파라미터의 값을 입력한다. 만약 숫자가 들어가야 하는 곳에 문자를 넣는 것처럼 타입이 맞지 않을 경우 BindException이 발생한다.

3-2. 만약 애노테이션을 생략한 상태로 파라미터를 작성하였을 때 String, int, Integer와 같은 단순 타입의 경우 @RequestParam으로 처리하고 그 외에는 @ModelAttribute으로 처리한다.(특정 객체를 생성하는, ArgumentResolver로 지정된 일부 타입 제외)

 

 

HTTP 요청 메시지

요청 파라미터의 경우와 달리 HTTP 메시지 바디를 통해 데이터가 직접 넘어오는 경우 @RequestParam과 @ModelAttribute를 사용할 수 없다. 기본적으로 메시지 바디의 데이터는 InputStream을 이용해 읽을 수 있는데, 스프링 MVC를 이용하면 HttpServletRequest, InputStream, HttpEntity / RequestEntity 중 하나를 골라 파라미터로 받음으로써 데이터를 조회할 수도 있다.

 

하지만 헤더 정보가 필요 없을 경우 @RequestBody 애노테이션을 이용해 바디 정보를 편리하게 조회할 수 있다.

특히 HTTP API에서 주로 사용하는 JSON 데이터 형식을 객체로 변환하기 위해서는 메시지 바디의 데이터를 문자로 변환하고 자바 객체로 변환하는 과정이 필요한데, 해당 애노테이션을 사용하게 된다면 @RequestBody HelloData data와 같이 별도의 로직을 작성하지 않고도 파라미터를 통해 객체를 처리할 수 있다.

하지만 @RequestBody는 생략이 불가능하다. 위에서도 언급했듯이 애노테이션을 생략한 채 파라미터를 작성하면 HTTP 메시지 바디가 아닌 요청 파라미터를 처리하게 되기 때문이다. 또한 HTTP 요청 시 content-type이 application/json이어야 JSON을 처리할 수 있다.

 

 

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

정적 리소스

정적 리소스는 파일을 변경 없이 그대로 서비스하는 것으로, src/main/resources에 리소스를 넣어두면 스프링 부트가 정적 리소스로 서비스를 제공한다.

 

뷰 템플릿

일반적으로는 HTML을 동적으로 생성하는 용도로 사용하며, 뷰 템플릿을 거쳐 HTML이 생성되고 뷰가 응답을 만들어 전달한다.

스프링 부트는 기본적으로 src/main/resources/templates이라는 뷰 템플릿 경로를 제공한다.

 

 

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

HTTP 요청 메시지와 마찬가지로 HttpServletResponse를 이용할 수 있지만, HttpEntity를 상속받은 ResponseEntity 또는 @ResponseBody 애노테이션을 이용하면 HTTP 메시지를 직접 입력할 수 있다.

 

ResponseEntity와 @ResponseBody

HTTP 메시지를 직접 입력할 수 있다는 공통점을 가지고 있지만, 다음과 같은 차이점들이 존재한다.

- ResponseEntity는 HTTP 응답 코드를 지정하는 것이 자체적으로 가능하지만, @ResponseBody는 응답 코드를 지정할 수 있는 별도의 속성 값을 자체적으로 갖추고 있지 않아 @ResponseStatus와 같은 부가적인 애노테이션을 사용해야 한다. 그렇다고 해서 동적으로 응답 코드를 변경할 수는 없기 때문에 필요하다면 조건에 따라 ResponseEntity를 이용하도록 설계하면 된다.

 

 

HTTP 메시지 컨버터

뷰 템플릿으로 HTML을 생성해서 응답하는 것이 아닌, HTTP API처럼 JSON 데이터를 HTTP 바디에서 직접 읽거나 쓰는 경우 HTTP 메시지 컨버터를 사용하면 편리하게 작업을 수행할 수 있다. 스프링 MVC는 다음의 경우에 HTTP 메시지 컨버터를 적용한다.

HTTP 요청: @RequestBody, HttpEntity(RequestEntity)

HTTP 응답: @ResponseBody, HttpEntity(ResponseEntity)

 

HTTP 메시지 컨버터 인터페이스는 특정 클래스 또는 미디어 타입을 지원하는지 체크하는 canRead()와 canWrite(), 메시지를 읽고 쓰는 read(), write() 메서드를 선언해 두었다. 스프링 부트는 다양한 메시지 컨버터를 제공하는데, 클래스 타입과 미디어 타입 지원 여부 두 가지를 체크하여 사용 여부를 결정한다.(만족하지 않을 경우 다음 우선순위로 이동하여 다시 체크)

1. HTTP 요청 데이터 읽기

HTTP 요청이 오고, 컨트롤러에서 @RequestBody 또는 HttpEntity를 사용한다면 메시지 컨버터가 메시지를 읽을 수 있는지 조건을 확인한다.(클래스 타입 지원 여부, 요청의 Content-Type 미디어 타입 지원 여부) 조건을 만족한다면 그에 맞는 객체를 생성해 반환한다.

2. HTTP 응답 데이터 생성

컨트롤러에서 @ResponseBody, HttpEntity를 통해 값이 반환된다면 메시지 컨버터가 메시지를 쓸 수 있는지 확인한다.(클래스 타입 지원 여부, 요청의 Accept 미디어 타입 지원 여부) 조건을 만족한다면 HTTP 응답 메시지 바디에 데이터를 생성한다.

 

스프링 부트가 제공하는 메시지 컨버터 중 주요한 컨버터는 다음과 같다.

1순위 - ByteArrayHttpMessageConverter

클래스 타입이 byte[]인 데이터를 처리한다. 미디어 타입의 제한은 없고, 응답 시 content-Type은 application/octet-stream이다.

2순위 - StringHttpMessageConverter

클래스 타입이 String인 데이터를 처리한다. 미디어 타입의 제한은 없고, 응답 시 content-Type은 text/plain이다.

3순위 - MappingJackson2HttpMessageConverter

클래스 타입이 객체이거나 HashMap이면서 미디어 타입이 application/json과 관련된 데이터를 처리한다.

 

 

 

요청 매핑 핸들러 어댑터(RequestMappingHandlerAdapter)

SpringMVC 구조

HTTP 메시지 컨버터

HandlerMethodArgumentResolver(ArgumentResolver)

애노테이션 기반의 컨트롤러는 파라미터로 들어오는 형식에 제한받지 않으면서 처리 가능한 유연성을 가지고 있는데, 이는 HandlerMethodArgumentResolver 인터페이스 덕분이다. 다양한 형식을 처리할 수 있도록 여러 구현체들을 만들어놓았기 때문에, 들어오는 형식에 맞추어 적합한 ArgumentResolver를 호출하여 처리할 수 있다.

 

RequestMappingHandlerAdapter(요청 매핑 핸들러 어댑터) 동작 방식

ArgumentResolver에서 컨트롤러의 파라미터, 애노테이션 정보를 기반으로 전달 데이터를 생성하여 핸들러를 호출한다. 핸들러에서 반환한 값은 HandlerMethodReturnValueHandler(ReturnValueHandler)에서 변환하는 과정을 거치게 된다.

 

HTTP 메시지 컨버터 위치

HTTP 메시지 컨버터는 @RequestMapping을 처리하는 핸들러 어댑터인 RequestMappingHandlerAdapter에서 동작한다.

기본적으로는 ArgumentResolver가 작업을 처리하는데, @RequestBody / @ResponseBody / HttpEntity와 같이 HTTP 처리가 필요한 경우 해당 ArgumentResolver가 HTTP 메시지 컨버터를 호출하여 관련 작업을 처리하도록 하는 것이다.