개발놀이터

*HTTP 요청메시지 - JSON -InputStream으로 읽어오는 방식 @PostMapping("/request-body-json-v1") public void requestBodyJsonV1(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { ServletInputStream inputStream = request.getInputStream(); String messageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8); log.info("messageBody={}", messageBody); HelloDa..

*HTTP 요청 메시지 - 단순 텍스트 HTTP message body에 데이터를 직접 담아서 요청 -HTTP API에서 주로 사용, JSON, XML, TEXT -데이터 형식은 주로 JSON 사용 -POST, PUT, PATCH 사용가능 요청 파라미터와 다르게, HTTP 메시지 바디를 통해 데이터가 직접 넘어오는 경우는 @RequestParam, @ModelAttribute를 사용할 수 없다. 이럴때는 InputStream으로 메시지 바디에 있는 내용을 읽어올 수 있다. @PostMapping("/request-body-string-v1") public void requestBodyString(HttpServletRequest request, HttpServletResponse response) thr..

*HTTP 요청 파라미터 - @RequestParam 스프링이 제공하는 @RequestParam을 사용하면 요청 파라미터를 매우 편리하게 사용할 수 있다. @RequestMapping("/request-param-v2") public String requestParamV2 (@RequestParam("username") String memberName, @RequestParam("age") int memberAge) { ... } 이런식으로 RequestParam을 이용하면 request.getParameter("username")과 같은 효과를 볼 수 있다. @RequestMapping("/request-param-v3) public String requestParamV3 (@RequestParam S..

*요청 매핑 *@RestController -@Controller는 반환 값이 String 이면 뷰 이름으로 인식된다. 그래서 뷰를 찾고 뷰가 랜더링 된다. -@RestController는 반환 값으로 뷰를 찾는 것이 아니라 HTTP메시지 바디에 바로 입력한다. @ResponseBody와 관련이 있는데 뒤에서 더 자세히 설명한다. *@RequestMapping("/hello-basic") -/hello-basic URL 호출이 오면 이 메서드가 실행되도록 매핑한다. -대부분 속성을 배열로 제공하므로 다중 설정이 가능하다. {"/hello-basic", "/hello-go"} RequestMapping은 뒤에 method를 한정지을 수 있는데 다음과 같이 적으면 된다. @RequestMapping(valu..

*로깅 운영 시스템에서는 System.out.println() 같은 시스템 콘솔을 사용해서 필요한 정보를 출력하지 않고, 별도의 로깅 라이브러리를 사용해서 로그를 출력한다. 참고로 로그 관련 라이브러리도 많고, 깊게 들어가면 끝이 없기 때문에, 여기서는 최소한의 사용 방법만 알아본다. *로깅 라이브러리 스프링 부트 라이브러리를 사용하면 스프링 부트 로깅 라이브러리가 함께 포함된다. 스프링 부트 로깅 라이브러리는 기본적으로 다음 로깅 라이브러리를 사용한다. -SLF4J : http://www.slf4j.org -Logback : http://logback.qos.ch 로그 라이브러리는 Logback, Log4J, Log4J2 등등 수 많은 라이브러리가 잇는데, 그것을 통합해서 인터페이스로 제공하는 것이 바..

*스프링 MVC 구조 스프링 MVC의 구조는 다음과 같다 1. HTTP요청이 들어오면 Front Controller인 Dispatcher Servlet이 모든 URL매핑에 반응한다. 2. 그 후에 핸들러(=컨트롤러) 매핑 정보를 기반으로 핸들러를 조회한다. 3. 핸들러마다 다른 기능을 지원하기 위해서 핸들러 어댑터 목록에서 핸들러를 처리할 수 있는 핸들러 어댑터를 조회한다. 4. 핸들러 어댑터를 들고 핸들러를 호출한다. 5. 핸들러를 호출하고 Model And View로 반환해준다. 6. viewResolver를 호출해서 View를 반환받는다. 7. render를 호출해서 랜더링한다. *@Controller -스프링이 자동으로 스프링 빈으로 등록한다. (내부에 @Component 어노테이션이 있어서 컴포..

*캐시와 조건부 동작 캐시가 없을 때 첫번째 요청 예를 들어서 클라이언트가 GET방식으로 star.jpg를 요청하면 서버는 클라이언트에게 star.jpg를 보내준다. 캐시가 없을 때 두번째 요청 두번째 클라이언트가 GET방식으로 star.jpg를 요청하면 서버는 또 클라이언트에게 star.jpg를 보내준다. 캐시가 없을 때는 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야한다. 인터넷 네트워크는 매우 느리고 비싸다. 브라우저는 로딩 속도가 느리다 때문에 느린 사용자 경험이 생긴다. 캐시를 적용할 때 cache-control: max-age=60(초)을 설정하면 캐시가 유효한 시간이 60초이다. 클라이언트가 최초로 요청하면 브라우저 캐시에 60초 유효한 star.jpg를 저장하고 ..

*HTTP 일반 헤더 HTTP헤더 용도 -HTTP 전송에 필요한 모든 부가정보 -ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보...등등 -표준 헤더가 너무 많음 -필요시 임의의 헤더 추가 가능 HTTP헤더 분류 (과거) -General 헤더 : 메시지 전체에 적용되는 정보 -Request 헤더 : 요청 정보 -Response 헤더 : 응답 정보 -Entity 헤더 : 엔티티 바디 정보 HTTP바디 (과거) -메시지 본문은 엔티티 본문을 전달하는데 사용 -엔티티 본문은 요청이나 응답에서 전달할 실제 데이터 -엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보 제공 (데이터 유형(html, json), 데이터 길이, 압축 정보 등등) ㅡ..

*HTTP 상태코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1. 1xx : 요청이 수신되어 처리중 2. 2xx : 요청 정상 처리 3. 3xx : 요청을 완료하려면 추가 해동이 필요 4. 4xx : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음 5. 5xx : 서버 오류, 서버가 정상 요청을 처리하지 못함 만약 모르는 상태코드가 나타나면? -클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면? -클라이언트는 상위 상태코드로 해석해서 처리 -미래에 새로운 상태코드가 추가되어도 클라이언트를 변경하지 않아도 됨 ex) 299 = 2xx = 요청이 정상처리 되었구나 ex) 451 = 4xx = 클라이언트 오류구나 1. 1xx 요청이 수신되어 처리중 넘어가도 됨 2. ..

*HTTP 메서드 HTTP API URI 설계 회원 목록 조회 / read-member-list 회원 조회 / read-member-by-id 회원 등록 / create-member 회원 수정 / update-member 회원 삭제 / delete-member 이렇게 설계하는게 좋은 설계일까? 가장 중요한 것은 리소스 식별! 리소스의 의미는 뭘까? -회원을 등록하고 수정하고 조회하는게 리소스가 아니다 -ex) 미네랄을 캐라 -> 미네랄이 리소스 -회원을 조회해라 = 리소스? (X) / 회원 자체가 바로 리소스 리소스를 어떻게 식별하는게 좋을까? -회원을 등록하고 수정하고 조회하는 것을 모두 배제 -회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑 다시 API URI 설계 회원 목록 조..