서블릿, JSP 만으로 비즈니스 로직과 뷰 렌더링 까지 모두 처리하게 되면, 너무 많은 역할을 하게되고, 유지보수가 어려워짐.
비즈니스 로직과 뷰를 구분하는것이 유지보수에 좋음.
dispatcher.forward()
: 다른 서블릿이나 JSP로 이동할 수 있는 기능. 서버내에서 다시 호출(redirect가 아님)
redirect vs forward 의 차이
redirect는 클라이언트에서 서버로 호출함
forward는 서버내부에서 일어나는 호출( 클라이언트가 인지 x)
프론트 컨트롤러 패턴(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가지