♪ 학습 내용 서버로 데이터 전송, HTTP API 설계 시 HTTP 메서드 활용 * 클라이언트 -> 서버 데이터 전달 방식 클라이언트에서 서버로 데이터를 전송하는 방식으로는 쿼리 파라미터를 통한 전송(GET) / 메시지 바디를 통한 전송(GET 외에) 두가지가 있다. - 정적 데이터 조회 이미지나 정적 텍스트 문서와 같은 정적 데이터를 조회할 때에는 단순히 URI의 리소스 경로만으로 조회 가능하다. 즉, GET메서드를 통해 조회하지만 쿼리 파라미터를 통한 데이터 전송을 할 필요가 없다. - 동적 데이터 조회 쿼리 파라미터를 사용해서 데이터를 전달. 서버는 쿼리 파라미터를 기반으로 결과를 동적으로 생성한다. 주로 검색어를 통해 조회 조건을 줄여주는 필터나, 조회 결과를 정렬하는 조건에서 사용된다. 어쨌거..

♪ 학습 내용 HTTP API 개발 및 HTTP 메서드 * URI 설계 처음 URI 설계 시에는 많은 사람들이 다음과 같이 설계하고는 한다. 회원 목록 조회 = /read-member-list 회원 등록 = /create-member 위 설계는 동사, 행위로 URI를 식별하고 있다. read 인지 create인지 delete인지 등등. (좋은 방법이 아니다.) 가장 좋은 방법은 리소스로 식별하는 것. 동사가 아닌 명사로 식별. '미네랄을 캐라' 에서 '캐라' 가 아닌 '미네랄' 이 리소스. 위의 설계에서 리소스는 '회원', member 이다. 때문에 동사는 다 배제하고 명사인 리소스만으로 URI에 매핑해 식별해야 한다. [ 리소스: 회원 ] / [ 행위: 조회, 등록, 삭제, 변경 ] 로 나눠짐. 그렇다..

♪ 학습 내용 HTTP의 기본 특성 * HTTP(Hyper Text Transfer Protocol) 현재 HTTP의 버전은 3까지 있고 주로 1.1 / 2 / 3 버전을 사용. 가장 중요한 것은 HTTP/1.1 이고 HTTP/2 와 HTTP/3 은 이를 개선시킨 것이다. 1.1과 2 버전은 TCP프로토콜 위에서, 3버전은 UDP프로토콜 위에서 동작한다. 앞에서 학습했듯이 TCP는 3-wayhandshake 로 비교적 느리고, UDP레벨에서 성능을 최적화 한 것이 바로 3버전. HTTP는 다음과 같은 특징을 지녔다. - 클라이언트 서버구조 - 무상태 프로토콜( stateless ) - 비연결성 - HTTP 메시지 * HTTP - 클라이언트 서버구조 HTTP는 클라이언트 서버구조이다. 말 그대로 클라이언트..

♪ 학습 내용 URI ( URL , URN ) / 웹의 흐름 * URI(Uniform Resource Identifier) URI는 통합 리소스 식별자이다. 여기서 말하는 리소스는 서버 내 자원으로, URI로 식별할 수 있는 모든 것을 의미함. URI는 큰 개념으로, 로케이터와 이름으로 분류 될 수 있다. 각각의 경우가 바로 URL( locator ) , URN( name ) 주의할 점은 URL과 URN이 아니여도 URI일 수 있다는 점! 두가지로 완전 이분화 되는 것은 아니다! 우리는 흔히 링크 보고 URL 이라고 부르곤 한다. URL은 리소스가 있는 위치를 지정하고, URN은 리소스에 이름을 부여한다. URN 이름만으로 리소스를 활용할 수 있는 방법은 보편화되어있지 않기 때문에 우리는 URI와 URL..

♪ 학습 내용 IP / TCP / UDP / PORT / DNS 컴퓨터는 다음과 같이 복잡한 인터넷 망을 이용하여 통신한다. 이와 관련된 개념들 * IP(인터넷 프로토콜) IP는 IP 주소를 부여해준다. like) 100.100.100.1 IP는 그렇게 지정된 주소에 데이터를 전달. 이때의 단위는 패킷이다. 패킷이란? 패키지(수하물) + 버킷(덩어리) 의 합성어로 전송할 것들을 모아놓은?정도. IP 패킷에는 데이터와 함께 출발지 IP와 목적지IP 등 기타 정보가 담겨있다. 클라이언트에서 서버로, 서버에서 클라이언트로 정보를 주고 받을 때 이 IP패킷을 주고 받는 것. 이러한 IP 프로토콜은 여러 한계를 지니고 있다. 1. 주소를 상대로 데이터를 전송하기 때문에, 대상 서비스가 불능인 경우에도 패킷을 전송..

♪ 학습 내용 웹 스코프 / 프록시 * 웹 스코프 앞에서 본 프로토타입 스코프는 요청 시에 생성하고 초기화까지만 진행, 반환. 더 이상 관리 x 웹 스코프는 스프링이 종료 시점까지 관리한다. 종류로는 request, session, application, websocket 이 중 request 스코프를 다뤘다. 프로토타입은 요청마다 새로운 생성했지만, request는 HTTP request에 요청이 들어오고 나갈때까지, 그 라이프 사이클 동안 유지된다. 그리고 각 요청마다 새로 생성하여 다른 인스턴스를 넘김!! 만약 같은 요청이 Controller 외에 Service에서도 호출되면 같은 인스턴스를 반환 (각각의 요청마다 이므로) 실행하면 오류 발생한다 왜?? @RequiredArgsConstructor ..

♪ 학습 내용 싱글톤 빈과 프로토타입 빈 충돌 시 * 싱글톤 빈과 프로토타입 빈 함께 사용시 문제 싱글톤 빈인 ClientBean이 생성자 주입으로 프로토타입 빈을 주입 받는 상황을 가정해보면 ClientBean은 싱글톤이기에 컨테이너에서 쭉 관리. 따라서 여러 고객이 ClientBean을 요청해도 같은 인스턴스를 반환해준다. 문제는 생성자 주입으로 프로토타입 빈과 의존관계를 맺기 때문에, 여러 고객이 요청한 ClientBean 이 의존하는 프로토타입 빈도 전부 같은 인스턴스이다. 빈 스코프가 프로토타입이면 매 요청시 새로운 빈을 반환해야 하는데 그게 깨져버린 상황 발생! 즉 주입 시전에 프로토타입 빈이 새로 생성되는 것이지, 요청마다 새로 생성되는 것이 아님. 원하는 건 싱글톤 빈에서도 해당 프로토타입..

♪ 학습 내용 빈 스코프 / 싱글톤 스코프 / 프로토타입 스코프 * 빈 스코프란 무엇인가 빈 스코프란 무엇인가?? 스코프에 대해서는 jsp 맛보기 공부하거나 spring 입문 강의할 때 몇번 듣고 사용해봤는데 사실 잘 모른다. 대충 느낌적으로는 영역? 이정도로 이해하고 있다. - 스코프는 빈이 존재할 수 있는 범위를 뜻한다. 스코프의 종류는 다음과 같이 다양하다 싱글톤 스코프(디폴트) / 프로토타입 스코프 / 웹 관련 스코프( request, session, application ) 등록할 때는 애노테이션을 이용해서 @Scope("singleton" 또는 "prototype") @Component(자동 등록) 나 @Bean(수동등록) 에 붙는다. * 싱글톤 스코프 싱글톤 스코프가 바로 우리가 여태 사용해..

♪ 학습 내용 빈 생명주기 콜백 * 빈 생명주기 콜백 애플리케이션 시작 시점에 연결 미리 해두고 종료 이전에 연결을 종료(안전하게) ( like 애플리케이션 과 DB를 미리 연결 해두는 ) 를 위해서는 객체의 초기화, 종료작업 필요!! 스프링 빈은 다음과 같이 두 단계로 이루어진다는 것을 앞에서 학습했다. 1. 빈 객체 생성 2. 의존관계 주입 이 과정이 모두 끝난 후에야 데이터를 사용할 수 있는 준비 완료됨. 그렇다면 의존관계가 끝난 후에 초기화 작업을 해야하는데. 우리가 스프링 빈의 의존관계 주입이 끝났는 지 어떻게 알 수가 있나.. ? 초기화 콜백 ==> 의존관계 주입까지 끝났으니 이제 너 하고싶은 대로 마음대로 해 생성자 인젝션은 스프링 빈 생성과 동시에 의존관계 주입을 한다는 것을 앞에서 학습했..

♪ 학습 내용 조회되는 동일 타입의 빈 모두 필요 할 경우 / 자동 또는 수동 빈 운영 기준 * 조회 빈 모두 이용 스프링 컨테이너에 등록된 빈 중 동일 타입이 있을 경우 오류 발생. 전 학습에서 우선순위를 두거나 고르는 방식으로 하나를 골라 조회했었다. 이번에는 조회되는 빈 모두를 이용..! List 와 Map 을 이용해본다 Map은 key 값으로 스프링 빈 이름이, value 값으로 DiscountPolicy 타입의 스프링 빈이 담아진다 (rateDiscountPolicy, fixDiscountPolicy 가 담아지겠지 ? ) 생성자 의존관계 주입 이용( 생성자가 하나이므로 @Autowired 지워도 똑같다 ) discountCode로 넘어오는 스프링 빈 이름으로 빈을 찾고, 해당 객체의 discou..