서블릿, JSP 만으로 비즈니스 로직과 뷰 렌더링 까지 모두 처리하게 되면, 너무 많은 역할을 하게되고, 유지보수가 어려워짐.

비즈니스 로직과 뷰를 구분하는것이 유지보수에 좋음.

dispatcher.forward() : 다른 서블릿이나 JSP로 이동할 수 있는 기능. 서버내에서 다시 호출(redirect가 아님)

redirect vs forward 의 차이

redirect는 클라이언트에서 서버로 호출함

forward는 서버내부에서 일어나는 호출( 클라이언트가 인지 x)

MVC 프레임워크

프론트 컨트롤러 패턴(dispatcher Servlet)

컨트롤러 앞에서 요청을 어느 컨트롤러로 보낼지 조율 해줌

어댑터 패턴

다양한 방식의 컨트롤러를 처리할 수 있도록 adapter를 만들고 어댑터 핸들러로 맞는 어댑터를 loop로 찾음

@Controller

@RequestMapping : mappingName과 method를 둘다 선언해 줘야함

@GetMapping → get만 받도록 가능 → method 선언 필요 x

@PostMapping → post만 받도록 가능 → method 선언 필요 x

@RestController

Logging의 레벨

-trace

-debug

-info

-warn

-error

주로 개발서버는 debug레벨, 운영서버는 info레벨을 사용한다.

log사용시 주의 할점

<aside> 💡 log.trace(”trace log = ” + param); — 이렇게 쓰면 ‘+’로 인하여 연산이 일어나서 resource를 소비한다.(사용X) log.trace(”trace log = {}”, param); — 파라미터만 넘겨서 연산이 일어나지 않음(사용 O)

</aside>

@PathVariable 변수

아래와 같이 경로에 있는 텍스트를 그대로 가지고 와서 변수처럼 사용 할 수 있다.

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

변수 명과 path에 있는 텍스트가 동일 하면 @PathVariable뒤에 (”변수명”) 을 생략 가능하다.

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

요청시에 조건을 걸수도 있다.

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

미디어타입 조건을 걸수도 있다.(Content-Type : consume(소비), Accept : produce(제공))

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

MultiValueMap

HttpEntity

Http 응답 3가지