스프링 MVC 1 - 정리(스프링 MVC - 기본 기능)

정리(스프링 MVC - 기본 기능)

 

• 프로젝트 생성
• 로깅 간단히 알아보기
  • 로깅은 SLF4J와 Logback 라이브러리를 사용한다는 것을 알아보았다.
  • SLF4J는 인터페이스고,
  • SLF4J의 수많은 구현체중에 하나가 Logback 구현체이다.
  • 이것이 귀찮다면, 롬복의 @SLF4J를 사용해도 된다.
  • 그리고, 로그는 레벨이 있다.
    • LEVEL: TRACE > DEBUG > INFO > WARN > ERROR
  • 로그 사용의 장점은, 여러가지 부가 정보를 출력할 수 있고,  로그레벨에 따라 개발서버에서는 모든 로그를 출력하고, 운영서버에서는 특정 레벨의 로그만 출력하도록 상황에 맞게 조절할 수 있다.
• 요청매핑
  • 요청 매핑은 @RequestMapping 가장 간단한 것 부터 url뿐만 아니라 메서드까지 매핑하는 것을 해봤고,
  • 이 두가지를 축약해서 @GetMapping 같은 것을 이용할 수 있었고,
  • PathVariable에 대해서도 알아보았다. 다중으로도 가능하다.
  • 그리고 파라미터 접근도 매핑할 수 있었다.
  • 그리고 헤더에 특정 헤더가 있는지 없는지에 대한 것도 매핑할 수 있었다.
  • content-type에 들어온 미디어타입을 가지고도 매핑할 수 있다.
  • 서버가 소비할 미디어 타입은 consumes로 매핑
  • 클라이언트가 받을 수 있는 accept로 들어온 것은 produces로 통해 매핑할 수 있다.
• 요청 매핑 - API 예시
• HTTP 요청 - 기본, 헤더 조회
• HTTP 요청 파라미터 - 쿼리 파라미터, HTML Form
  • 클라이언트에서 서버로 요청 데이터를 전달할 때는 주로 3가지 방법을 사용한다.
    • GET - 쿼리 파라미터 (request.getParameter (@RequestParam) 으로 처리)
    • POST - HTML Form (request.getParameter (@RequestParam)으로 처리)
    • HTTP message body (이건 보통 메세지 컨버터로 처리함)
• HTTP 요청 파라미터 @RequestParam
  • 파라미터 변수명이 같으면 생략이 가능한 것도 확인, required, defaultValue 에 대해서도 알아보았음
• HTTP 요청 파라미터  @ModelAttribute
  • @ModelAttribute는 생략할 수 있다. 그런데 @RequestParam도 생략할 수 있으나, 혼란이 발생할 수 있어서 스프링은 규칙을 적용했다.
    • String, int, Integer 같은 단순 타입 = @RequestParam
    • 나머지 = @ModelAttribute (argument resolver로 지정해둔 타입 외)
• HTTP 요청 메시지 - 단순 텍스트
  • 보통 JSON을 사용하고, POST, PUT, PATCH로 넘어온다.
  • 단순 텍스트에는 @RequestParam이나 @ModelAttribute와 전혀 상관이 없다.
• HTTP 요청 메시지 - JSON
  • JSON도 @RequestBody에 객체를 넣고, Content-type이 Apllication/JSON으로 넘어오게 되면,
    잭슨메시지컨버터가 동작하면서 우리가 원래 직접 objectMapper에 넣어줬던 것들을 자동으로 처리해준다.
  • 이때 @RequestBody는 생략이 불가능하다. 만약에 생략하면 스프링 규칙에 의해 @ModelAttribute가 들어가기 때문이다.
  • 그래서 HTTP 요청 시에 content-type이 application/json인지 꼭 확인해야 한다. 그래야 JSON을 처리할 수 있는 HTTP 메시지 컨버터가 실행된다.
  • HttpEntity도 마찬가지이다.
• HTTP 응답 - 정적 리소스, 뷰 템플릿
  • HTTP 응답도 3가지로 나눌 수 있다.
    • 정적 리소스
      • 웹 브라우저에 정적인 HTML, css, js을 제공할 때는 정적 리소스를 사용한다.
    • 뷰 템플릿 사용
      • 예) 웹 브라우저에 동적인 HTML을 제공할 때는 뷰 템플릿을 사용한다.
    • HTTP 메시지 사용
      • HTTP API를 제공하는 경우에는 HTML이 아니라 데이터를 전달해야 하므로, HTTP 메시지 바디에 JSON 같은 형식으로 데이터를 실어 보낸다.
• HTTP 응답 - HTTP API, 메시지 바디에 직접 입력
  • @RestController
  • 만약에 @ResponseBody가 적용된 @RestController를 사용하면, 상태코드 변환하기 어려운데,
    이것은 @ResponseStatus 애노테이션을 사용하면 편리하다.
  • 그리고 만약에 정적으로 상태코드를 지정하는 것이아니라,
    동적으로 상태코드를 지정해야 하면,ResponseEntity를 사용해야 한다.
• HTTP 메시지 컨버터
  • HTTP 메시지 컨버터는 인터페이스로 이루어져있다.
    • canRead
    • canwrite
    • 이 두가지에서 클래스의 타입과 미디어타입이 항상 체크된다.
      • content-type이 application/json이고 String이면 StringHttpMessageConverter가 선택된다.
      • content-type이 application/json이고 객체가 들어오면 MappingJackson2HttpMessageConverter가 선택된다.
• 요청 매핑 핸들러 어댑터 구조
  • RequestMappingHandlerAdapter에서 ArgumentResolver를 호출하고, ArgumentResolver에서  핸들러(컨트롤러)에 필요한 데이터를 생성해서 RequestMappingHandlerAdapter에 넘겨준다.
    이때 만약 필요한 데이터가 @RequestBody 혹은 HttpEntity 종류인 경우에 한해서만 Http메시지 컨버터가 호출되어 사용된다.
    ArgumentResolver는 만든 데이터를 RequestMappingHandlerAdapter로 주고, 해당 데이터를 넘기면서 Handler를 호출한다.
  • 핸들러(컨트롤러에서)가 리턴할 때도 ReturValueHandler가 사용되는데 ArgumentResolver와 같다고 보면 된다.
• 정리