[스프링 MVC 1편] #6. 스프링 MVC - 기본 기능 (1)

[seyxxn]

6_스프링 MVC - 기본 기능 (1)

프로젝트 생성

• 스프링 프로젝트 생성

로깅 간단히 알아보기

• 운영 시스템에서는 System.out.println()같은 시스템 콘솔로 정보를 출력하지 않고, 별도의 로깅 라이브러리를 사용하여 로그를 출력

로그가 아닌 System.out.print()로 콘솔에 기록을 남길 수 있으나 이를 사용하면 문제가 있다. print() 메서드를 살펴보면 synchronzied로 동기화가 되어있는 것을 볼 수 있다. 그러면 기록을 남길 때마다 쓰레드 lock이 걸리기 때문에 엄청난 성능 저하를 불러일으키게 된다. 혹여나 개발 단계에서 이를 사용했다 하더라도 운영시에는 이를 모두 삭제해줘야 한다. 방치하면 I/O 요청이 발생할 때마다 쓸데없는 리소스를 잡아먹게 된다.

• 로그와 관련된 라이브러리가 매우 많기에, 최소한의 사용 방법만 알아본다

로깅 라이브러리

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

• 스프링부트 로깅 라이브러리는 기본으로 다음 로깅 라이브러리를 사용
  • SLF4J
  • Logback
• 로그 라이브러리는 Logback, Log4J, Log4J2 등 수 많은 라이브러리 존재, 그것을 통합하여 인터페이스로 제공하는 것이 SLF4J 라이브러리
• 즉, SLF4J는 인터페이스이고, 그 구현체 중 하나인 Logback을 로그 라이브러리로 선택하는 것
• 실무에서는 대부분 스프링부트가 기본으로 제공하는 Logback을 사용

로그 선언

• private Logger log = LoggerFactory.getLogger(getClass());
• private static final Logger log = LoggerFactory.getLogger(Xxx.class)
• @Slf4j: 롬복 사용 가능
  • 위 애노테이션을 사용하면 log를 따로 정의하지 않아도 편리하게 로그를 찍을 수 있다

로그 호출

• 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 {

    // @Slf4j를 사용하면 Log를 따로 정의하지 않아도 편리하게 log를 찍을 수 있다
   // private final Logger log = LoggerFactory.getLogger(getClass());

    @RequestMapping("/log-test")
    public String logTest() {
        String name = "Spring"; // 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 계산 로직이 먼저 실행됨
        // 이런 방식으로 사용하면 안됨 (자바 언어의 특성과 관련)         
        log.debug("String concat log=" + name);

        return "ok";
    }
}

매핑 정보

• @RestController
  • 스프링은 기본적으로 @Controller (일반 컨트롤러 애노테이션)을 사용하는데, 이 애노테이션을 사용하게되면 반환 값이 String인 경우, 뷰 이름으로 인식된다. 따라서, 뷰를 찾고, 뷰가 렌더링된다.
  • @RestController을 사용하면, 문자를 반환할 때 그 문자가 바로 그대로 반환이 된다.
  • 즉, 반환 값으로 뷰를 찾는 것이 아니라, HTTP 메세지 바디에 바로 입력한다. 따라서 테스트시에 간단하게 시용할 수 있다.

출력 결과 1

• log.info("info log={}", name); 로그 출력 결과
• 콘솔에 출력한 것 (name = Spring) 출력
• 로그는 실행 일자, 현재 컨트롤러 이름(LogTestController), 메세지(info log=Spring)까지 출력

테스트

• 로그 레벨 설정을 변경하여 로그 출력 결과를 다르게 출력할 수 있다
  • 개발 서버는 debug
  • 운영 서버는 info
• 로그 레벨
  • TRACE > DEBUG > INFO > WARN > ERROR
• log.debug -> 현재 로그는 디버그할 때 보는 것 (개발 서버같은 데서 보는 것)
• log.info -> 현재 로그는 중요한 정보 (비즈니스 정보거나 꼭 운영 시스템에서 봐야 할 정보)
• log.warn -> 경고, 위험한 정보
• log.error -> 에정

출력 결과 2

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

• 위 코드로 로그를 출력시키면, 다음과 같은 출력결과를 얻을 수 있다.

• 로그 레벨이 기본적으로 info로 설정되어있기에, trace와 debug는 출력되지 않는다

• 만약 더 많은 레벨의 로그를 출력하고 싶다면, 로그 레벨 설정 정보를 추가하면 된다

• application.properties

  # 전체 로그 레벨 설정(기본 info)
  logging.level.root = info
  
  # hello.springmvc 패키지와 그 하위 로그 레벨 설정
  logging.level.hello.springmvc = debug
  

  

  • debug로 설정하면, trace를 제외한 debug 로그 정보부터 출력

  

  • trace로 설정하면, 5가지 로그 정보가 모두 출력

올바른 로그 사용법

• log.info("info log={}", name); 이렇게 사용하지 않고 log.info("info log=" + name); 이렇게 사용해도 로그가 출력은 되나, 이렇게 사용하면 X
• 자바 언어의 특징과 관련
  • 메서드가 호출되기 전에, 문자열을 먼저 더함 (문자열 더하기 연산이 먼저 일어나기 때문)
  • 이 과정에서 메모리도 사용 하고 cpu를 사용
  • 하지만, 출력하지 않아도 되는 레벨의 로그인 경우 출력하지 않아도 되는데 문자 더하기가 일어나기에 쓸모없는 리소스를 사용하게 됨

로그 사용시 장점

• 쓰레드 정보, 클래스 이름 같은 부가 정보를 함께 볼 수 있고, 출력 모양을 조정할 수 있다.
• 로그 레벨에 따라 개발 서버에서는 모든 로그를 출력하고, 운영 서버에서는 출력하지 않는 등 로그를 상황에 맞게 조절할 수 있다.
• 시스템 아웃 콘솔에만 출력하는 것이 아니라, 파일이나 네트워크 등, 로그를 별도의 위치에 남길 수 있다. 특히 파일로 남길 때는 일별, 특정 용량에 따라 로그를 분할하는 것도 가능하다.
• 성능도 일반 System.out보다 좋다. (내부 버퍼링, 멀티 쓰레드 등등) 그래서 실무에서는 꼭 로그를 사용해야 한다.

요청 매핑

• 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());

    // @RequestMapping을 통해, 이 URL이 오면 이 메서드를 호출함을 맵핑
    @RequestMapping(value = "/hello-basic")
    public String helloBasic() {
        log.info("helloBasic");
        return "ok";
    }

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

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

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

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

    /**
     * 파라미터로 추가 매핑
     * params="mode", -> 파라미터 이름만 써도 된다
     * params="!mode" -> mode가 없어야 한다
     * params="mode=debug" -> mode=debug가 있어야 한다
     * params="mode!=debug" (! = ) -> mode가 디버그가 아니여야 한다
     * params = {"mode=debug","data=good"}
     */
    // 파라미터에 ?mode=debug가 없으면 BadRequest가 됨 (특정 파라미터 정보가 있어야 호출이 된다)
    // URL 경로뿐만 아니라 파라미터 정보까지 추가로 더 매핑한 것이다
    @GetMapping(value = "/mapping-param", params = "mode=debug") public String mappingParam() {
        log.info("mappingParam");
        return "ok";
    }

    /**
     * 특정 헤더로 추가 매핑
     * 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";
    }

    /**
     * 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";
    }

    /**
     * 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 메서드

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

HTTP 메서드 매핑

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

• method 속성을 GET으로 설정했기 때문에 GET만 허용한다.
• 만약 여기에 POST 요청을 하면 스프링 MVC는 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
     */
    @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 경로를 템플릿화 할 수 있는데, @PathVariavle을 사용하면 매칭 되는 부분을 편리하게 조회할 수 있다.
• @PathVariable의 이름과 파라미터 이름이 같으면 생략할 수 있다.

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

PathVariable 사용 - 다중

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

• @PathVariable을 사용하여 2개 이상의 파라미터 이름과 매핑도 가능하다

특정 파라미터 조건 매핑

    /**
     * 파라미터로 추가 매핑
     * params="mode", -> 파라미터 이름만 써도 된다
     * params="!mode" -> mode가 없어야 한다
     * params="mode=debug" -> mode=debug가 있어야 한다
     * params="mode!=debug" (! = ) -> mode가 디버그가 아니여야 한다
     * params = {"mode=debug","data=good"}
     */

    // 파라미터에 ?mode=debug가 없으면 BadRequest가 됨 (특정 파라미터 정보가 있어야 호출이 된다)
    // URL 경로뿐만 아니라 파라미터 정보까지 추가로 더 매핑한 것이다
    @GetMapping(value = "/mapping-param", params = "mode=debug") public String mappingParam() {
        log.info("mappingParam");
        return "ok";
    }

• 특정 파라미터가 있거나 없는 조건을 추가할 수 있다. 잘 사용하지는 않음

특정 헤더 조건 매핑

    /**
     * 특정 헤더로 추가 매핑
     * 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) 반환

미디어 타입 조건 매핑 - 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 요청의 Accept 헤더를 기반으로 미디어 타입으로 매핑
• 만약 맞지 않으면 HTTP 406 상태코드(Not Acceptable)을 반환

요청 매핑 - API 예시

회원 관리 API

기능	Method	URI
회원 목록 조회	GET	/users
회원 등록	POST	/users
회원 조회	GET	/users/{userId}
회원 수정	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 {

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

API test Example

기능	Method	URI
회원 목록 조회	GET	/mapping/users
회원 등록	POST	/mapping/users
회원 조회	GET	/mapping/users/id1
회원 수정	PATCH	/mapping/users/id1
회원 삭제	DELETE	/mapping/users/id1

• 매핑까지 완료, 다음부터는 HTTP 요청이 보내는 데이터들을 스프링 MVC로 어떻게 조회하는지 알아보자

🔗 출처

• 김영한 - 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

[6om1n]

표로 정리하니까 너무 깔끔하네요 >!! 👏 👏

[seyxxn]

깔끔할 것 같아서 해봤습니다 ㅎㅅㅎ~🤭

[YuDeokRin]

오 표로 하는 방법도...있군요 한 수 배워갑니다.