노릇노릇 식빵굽는 이야기

- 기본 형식 : header-field = field-name ":" OWS field-value OWS (OWS : 띄워쓰기)- field-name은 대소문자 구분이 없음 * 용도- HTTP 전송에 필요한 모든 부가 정보를 포함함 ex) message body 내용, message body 크기, 압축, 인증, 요청 Client, Server 정보, 캐시 관리 정보 등등- 표준 헤더가 많으며, 필요한 경우 임의의 header 추가 가능 ex) helloworld: hi * RFC2616 : 과거에 사용되었던 header- 분류 방식ㄴ General Header : message 전체에 적용되는 정보 ex) Connection : closeㄴ Request Header ex..

state code : 응답에서 Client가 보낸 요청의 처리 상태를 알려주는 기능Client는 아래처럼 상위 상태코드로 해석해서 처리하면 됨추후에 새로운 상태 코드가 추가되어도, Client는 변경하지 않아도 됨*** 1xx : Informational. 요청이 수신되어 처리중 --> 현재는 거의 사용되지 않음*** 2xx : Successful. 요청 정상 처리 - 200 : OK ㄴ Client 요청을 성공적으로 처리 완료 - 201 : Created ㄴ Client 요청으로 서버에서 새로운 resource 생성 ㄴ 생성된 resource는 응답의 Location Header 필드로 식별 ex) Location : /members/100 - 202 : Accept..

* API URI 설계- URI 계층 구조를 활용하여 리소스 식별을 하는 것이 중요하다 ex) 회원 등록, 회원 수정, 회원 조회 등에서 resource는 회원이다. --> 회원 resource를 URI에 mapping해야한다.- URI는 resource만 식별함 - 리소스(명사)와 행위(동사)를 분리해야함 Method * GET : resource 조회- 데이터는 query(parameter, String)를 통해서 전달- message body 사용해서 데이터 전달 가능. but 지원하는 곳이 잘 없어서 권장하지 않음 * POST : 요청 데이터 처리.- message body 통해서 서버로 요청 데이터를 전달함 --> 서버는 요청 데이터 처리 (데이터 처리하는 모든 기능 수행)..

* HTTP : HyperText Transfer Protocol- HTTP 메세지에 거의 모든 형태의 데이터를 전송할 수 있음- 서버 간 데이터를 주고 받을 때도 대부분 HTTP 사용- HTTP/1.1, HTTP/2는 TCP 기반 프로토콜이며, HTTP/3은 UDP 기반 프로토콜이다.ㅏ - 현재 HTTP/1.1을 주로 사용한다 *** HTTP 특징 * 클라이언트 서버 구조- Request Response 구조 1) Client -> Server 요청 보내고 응답 대기. 2) Server -> 요청에 대한 결과를 만들어서 응답 * 무상태 프로토콜(stateless)- Stateful : Server가 Client 상태를 보존하지 못함 --> 중간에 Server가 바뀌는 경우 유지하지 ..

* 인터넷 프로토콜 스택 4계층- 애플리케이션 계층 : HTTP, FTP- 전송 계층 : TCP, UDP- 인터넷 계층 : IP- 네트워크 인터페이스 계층 * 메세지 전송 과정메세지 -> 애플리케이션(Socket 라이브러리) -> OS(TCP 정보 생성) -> OS(IP 패킷 생성) -> 네트워크 인터페이스(LAN 카드) * IP : internet protocol.- IP 주소에 데이터를 전달하기 위해 packet으로 전송- 클라이언트 -> 인터넷 -> 서버 전송 요청 시 출발 IP과 도착 IP를 확인하고 인터넷의 노드를 통해서 데이터 전달- 한계 - 비연결성 : 패킷 받을 대상이 없거나 서버가 불능한 상태여도 패킷을 전송한다 (받는 서버 상태 확인 불가능) - 비신뢰성 : 중간에 패킷이 사..

빈 스코프 : 빈이 존재할 수 있는 범위 - 싱글톤 : 기본 스코프. 스프링 컨테이너의 시작 ~ 종료까지 유지되는 가장 넓은 범위의 스코프 - 빈 조회 시 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈 반환 - 프로토타입 : 빈 생성 ~ 의존관게 주입까지만 관여. 매우 짧은 스코프 - 빈 조회 시 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환 - 프로토타입 빈을 관리할 책임 --> 프로토타입 빈을 받은 클라이언트에 있다 - @Predestory 등 메서드 불가능 - 종료를 직접 입력해야함 (ex : Prototype.destory) Singleton은 같은 주소를 사용하는 반면, Prototype은 새로운 주소를 발급함. - @Scope("singleton" ..

생성자는 필수 정보를 받고 객체를 메모리에 올리는 역할에 집중해야 함- 생성자 : 필수 파라미터를 받아 필드 채우는 가벼운 작업에 집중- 초기화(init) : 외부 시스템과 연결하는 등 무거운 작업 - 생성 이후 별도의 초기화 메서드에서 처리하는 것이 유지보수와 객체지향 설계 측면에서 훨씬 좋다 * 스프링 빈 이벤트 생명주기스프링 컨테이너 생성 --> 스프링 빈 생성 --> 의존관계 주입 --> 초기화 콜백 --> 사용 --> 소멸 전 콜백 --> 스프링 종료- 의존관계 주입의 시점 :객체를 만드는 것(new)과 데이터를 채우는 것(Setter)은 순서가 나뉘어 있음- 초기화 타이밍 : Connect와 같은 무거운 작업은 데이터가 다 채워진 의존관계 주입 완료 후에 일어나야 함- 종료의 필요성 :..

260419 국립중앙박물관 나들이를 나왔다. 기온이 2도 더 올랐다는데 덥다 못해 뜨겁다손 선풍기 챙기기를 잘했구나 어제의 내 자신 칭찬해~아오 더워 가는 길 국중박 경치 감상하쇼. 4시 쯤 만나서 들어가려 하니 박물관 마감이 5시 반이라고 한다.일찍 만났어야했나 싶지만 뭐 어쩌겠니!총 3층이니까 한 층당 20분 컷 한다는 마인드로 입장~ 그런데 늦게 입장해서 그런지 사람이 확실히 적긴 하다최근에 케데헌으로 국중박이 줄을 엄청 선다고 했는데다행이구만 음음 크기가 6.7m * 3.4m라고 한다.네비와 인공위성도 없던 저시절에 어떻게 걸어다니면서 그린걸까사회과 부도에서 보던 걸 직접 보니 익숙하면서도 새롭다 와중에 독도 조그만하게 보이는거 포인트. 높이가 13.5m라고 한다.목이 빠질뻔했지 뭐야~ (..

의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작한다.스프링 빈이 아닌 클래스에서 @Autowired 코드를 적용해도 동작하지 않는다. * 생성자 주입- 생성자를 통해서 의존관계 주입 받는 방법- 단, 생성자 호출 시점에 1번만 호출하는 것을 보장 --> 불변, 필수 의존관계에 사용- 오로지 생성자 주입 방식만 final 키워드 사용 가능. * 수정자 주입(setter 주입)- 객체를 우선 만들고, 나중에 setter 메서드를 통해 주입 받는 방법- Bean을 변경하거나, Bean 없이도 객체를 우선적으로 생성할 수 있음 --> 주입할 대상이 없는 경우 : @Autowired(required = false) * 필드 주입- 필드에 바로 주입하는 방법으로, 한 줄로 나와서 코드가..

Singleton : 객체는 하나만 존재해야하는 것1. static 영역에 객체 1개만 미리 생성2. public으로 열어서 객체 인스턴스가 필요 시 static method를 통해서만 조회하도록 허용3. 생성자를 private로 선언 --> 외부에서 new 키워드 사용한 객체 생성을 못하게 막음 따라서 객체는 미리 1개만 만들어두고, 새로운 객체를 만드는 것을 방지.getInstance()를 통해 객체를 조회하게끔 하여 모든 사용자가 동일한 객체를 이용하도록 함 * 단점- 클라이언트가 구체 클래스에 의존 --> DIP, OCP 위반- 테스트가 어려움- 내부 속성의 변경이나 초기화가 어려움- private 생성자로 자식 클래스 만들기 어려움------> 유연성이 떨어짐 이러한 단점들을 보완하기 위해..