#1 HTTP 요청 매핑과 기본 로깅

# 간단한 Logging (@Slf4j)

웹 서버에서는 System.out.println으로 로그를 찍기에는 무리가 있다. 스프링부트에 포함된 로깅 라이브러리 (slf4j)를 간단하게만 배워보자. 참고로 slf4j는 Logback, Log4J, Log4J2 등의 라이브러리를 통합해서 사용할 수 있도록 만든 인터페이스이다. 스프링 프레임워크에서는 Logback을 기본으로 지원하고 있다.

• SLF4J (인터페이스) - http://www.slf4j.org
• Logback (구현체) - http://logback.qos.ch

(참고) @Controller와 @RestController의 차이

@Controller 는 반환 값이 String 이면 뷰 이름으로 인식된다. 그래서 뷰를 찾고 뷰가 랜더링 된다.

 

@RestController 는 반환 값으로 뷰를 찾는 것이 아니라, HTTP 메시지 바디에 바로 입력한다.

이는 REST API에 주로 사용되며 @ResponseBody 와 관련이 있는데, 나중에 추가로 설명하도록 하겠다.

// @Controller 반환 값을 View 이름으로 취급하고, 해당 View 를 찾아 반환된다.
@RestController // 반환 값을 문자열 그대로 전달한다. 보통 REST API에 사용된다.
public class LogTestController {
    private final Logger log = LoggerFactory.getLogger(getClass());
    // 다른 클래스를 Logger 에 등록하고 싶은 경우 아래와 같이 하면 된다.
    // private static final Logger log = LoggerFactory.getLogger(Xxx.class)

    @RequestMapping("/log-test")
    public String logTest() {
        String name = "Spring";
		
        // 로그 레벨을 지정할 수 있다.
        // TRACE > DEBUG > INFO(기본 값) > WARN > ERROR
        log.trace("lv 1추적 log={}", name);
        log.debug("lv 2디버그 log={}", name);
        log.info(" lv 3정보 log={}", name);
        log.warn(" lv 4경고 log={}", name);
        log.error("lv 5에러 log={}", name);

        // 참고로 아래와 같이 String 덧셈 연산을 사용하면 안된다.
        // 이는 JAVA의 String 연산과 관련이 있다. 스트링 덧셈은 객체가 로딩 될 때 미리 실행되어 최적화된다.
        // 즉 로그를 사용하지 않아도 a+b 계산 로직이 실행되며 리소스를 낭비하기 때문이다.
//        log.debug("String concat log=" + name);
        return "ok";
    }
}

참고로 lombok에 있는 @Slf4j 를 사용하면 Logger를 등록하는 코드를 생략할 수 있다.

@Slf4j
@RestController
public class LogTestController {
    // Logger 생성코드 필요없음. lombok이 생성
    
    @RequestMapping("/log-test")
    public String logTest() {...}
}

스프링에서 띄워지는 로그는 기본적으로 Slf4j - Logback을 사용해서 콘솔창에 띄운다.

2021-08-11 07:14:16.825  WARN   23784     --- [nio-8080-exec-1] hello.myClass       :  경고 log=Spring
2021-08-11 07:14:16.825  종류   프로세스ID --- [스레드 이름]      Controller 클래스   :  메시지

 

참고로 설정한 로그레벨 (debug, info)는 설정을 통해 특정 로그 레벨만 숨기거나 보이게 할 수 있다. 당연한 거지만 디버깅할 때 필요한 정보를 운영 서버에 띄우면 요청에 따라 엄청난 량의 쓸모없는 로그가 출력됨을 유의하자.

# resources/application.yaml

# 전체 로그레벨
logging.level.root = info

# 특정 패키지만 적용
logging.level.hello.package = debug

 

@ 콘솔에 찍는 거랑 뭐가 다르죠?

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

로깅 기능을 간단하게 설명했지만, 깊게 들어가면 이것도 공부할 내용이 많다. 일단은 이 정도만 알고 넘어가도록 하자.

---

# 요청 매핑하기 (@Controller)

요청이 왔을 때 어떤 스프링 빈(서블릿 역할)이 실행되어야 하는가?

• @Controller 는 반환 값이 String 이면 뷰 이름으로 인식된다. 그래서 뷰를 찾고 뷰가 랜더링 된다.
• @RestController 는 반환 값으로 뷰를 찾는 것이 아니라, HTTP 메시지 바디에 바로 입력한다.

우리는 만들어둔 View(HTML 또는 템플릿)가 없으므로, @RestContoller를 통해 매핑 방법을 배워보자. 

참고로 jiwon.com/hello 와 jiwon.com/hello/ 는 HTTP상으로 다른 요청이지만, 스프링은 같은 요청으로 매핑한다.

@Slf4j
@RestController
public class MappingController {
	
    // 여러 개를 매핑 하고싶다면 ({"/hello1" , "/hello2"})
    @RequestMapping("/hello-basic")
    public String helloBasic() {
        log.info("helloBasic");
        return "ok";
    }
}

 

위와 같이 HTTP Method를 지정하지 않으면 모든 요청(GET, HEAD, POST..)를 다 받아들인다. 아래와 같이 지정해주자.

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

 

좀 더 직관적으로 사용하기 위해서 스프링에서는 축약형(@GetMapping, @PostMapping)도 제공한다. 동작은 위와 같다.

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

 

참고로 잘못된 메서드로 요청하는 경우 스프링에서 JSON 형식으로 오류를 반환하는데, 이는 RestContoller를 사용해서 그렇다. 이는 나중에 예외처리를 배우며 알게 되니 일단 넘어가도록 하자.

---

@ PathVariable, 경로 변수

요청 매핑을 변수를 통해 지정할 수 있다. 지정하고 싶은 변수 앞에 @PathVariable("~")을 적으면 된다. 옛날에는 파라미터( a.com/hello?userId=3)를 많이사용했는데, 최근의 API는 이렇게 식별자를 넣는 스타일을 더 선호한다. 

# 쿼리 파라메타
http://a.com/mapping?users=userA&orders=100

# http://a.com/mapping/users/{userId}/orders/{orderId}
http://a.com/mapping/users/userA/orders/100

@GetMapping("/mapping/{userId}")
public String mappingPath(@PathVariable("userId") String data) {
 log.info("mappingPath userId={}", data); // {userId}에 data가 들어간다.
 return "ok";
}

// 참고로 {~}와 같은 이름의 변수를 사용하면, 생략해서 사용 가능하다.
@GetMapping("/mapping/{userId}")
public String mappingPath(@PathVariable userId) {
 log.info("mappingPath userId={}", data);
 return "ok";
}

---

@ 파라메타 조건 매핑

위의 @PathVariable 때문에 잘 사용하지는 않지만, 특정 쿼리 파라미터가 있을 때만 실행되도록 매핑할 수 있다.

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

400 오류코드와 함께 잘못된 요청이라고 응답한다.

 

@ 미디어 타입 조건 매핑

consumes ="~" 이용해서 HTTP 헤더를 확인해 특정 데이터의 타입만 받도록 만들수도 있다.

content-type이라고 적지 않고 컨슘을 사용하는 이유는 서버에서 사용하는(consumes) 데이터와 생산(produces)하는 데이터 타입을 따로 지정하기 위함이다.

/**
 * Content-Type 헤더 기반 추가 매핑 Media Type
 * consumes = "text/plain"
 * consumes ="!application/json" (Json이 아닌 데이터만 허용)
 * consumes = {"text/plain", "application/*"}
 * consumes = MediaType.TEXT_PLAIN_VALUE (상수 사용)
 */
@PostMapping(value = "/mapping-consume", consumes = "application/json")
public String mappingConsumes() {
    log.info("mappingConsumes");
    return "ok";
}

// 클라이언트가 보낸 Accept 헤더와 비교해서 동작한다. 만약 다르다면 406 오류코드를 반환한다.
@PostMapping(value = "/mapping-produce", produces = "text/html")
public String mappingProduces() {
    log.info("mappingProduces");
    return "ok";
}