Jay

PUT 리소스를 대체 리소스가 있으면 대체 리소스가 없으면 생성 쉽게 이야기해서 덮어버린다. 중요! 클라이언트가 리소스를 식별 클라이언트가 리소스 위치를 알고 URI 지정 POST와 차이점 PUT으로 리소스를 날리는 경우 날린 데이터로 기존의 데이터를 대체한다. 리소스가 없는 경우에는 신규 리소스를 생성한다. 즉 리소스를 완전히 대체한다. 전달할 데이터에 username 필드가 없다? 그러면 username 필드가 삭제된다. PATCH를 써보자. 부분적으로 age라는 리소스의 데이터를 변경하고 싶다. 가능하다! 만약 PATCH를 지원안하는 서버가 있을 수도 있다. (HTTP 자체에서 PATCH를 못 받아들이는 경우인데 그럴 때는 POST를 쓰자. POST는 무적이다.) DELETE는 말그대로 DELETE..

HTTP 메서드 종류를 알아보자. 주요 메서드 GET: 리소스 조회 POST: 요청 데이터 처리, 주로 등록에 사용 PUT: 리소스를 대체, 해당 리소스가 없으면 생성 PATCH: 리소스 부분 변경 DELETE: 리소스 삭제 기타 메서드 HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환 OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용) CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정 TRACE: 대상 리소스에 대한 경로를 따라서 메시지 루프백 테스트를 수행 GET 리소스 조회 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해서 전달. 메시지 바디를 사용해서 데이터 전달 가능하지만, 지원하지..

API 설계를 해보자. 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 아래의 좋지 않은 설계를 보자. 회원 목록 조회 / read-member-list 회원 조회 / read-member-by-id 회원 등록 / creadte-member 회원 수정 / update-member 회원 삭제 / delete-member 가장 중요한 것은 리소스 식별이다. API URI 고민 리소스의 의미는? 회원을 등록하고 수정하고 조회하는게 리소스는 아님 회원이라는 개념 자체가 바로 리소스 리소스를 어떻게 식별할까 회원을 등록하고 수정하고 조회하는 것을 모두 배제 회원이라는 리소스만 식별하자. 회원 리소스를 URI에 매핑 리소스 식별, URI 계층 구조 활용(URI 설계는 리소스 식별 + URI 계층 구조로 ..

HTTP 요청 메시지와 응답 메시지의 구조가 서로 다르다 http 메시지 공식 스펙 https://tools.ietf.org/html/rfc7230#section-3 시작 라인 요청 메시지 start - line = request-line / status - line request - line = method SP(공백) request-target SP HTTP-version CRLF(엔터) HTTP 메서드 (GET: 조회) 요청 대상 (/search?q=hello&hl=ko) / HTTP Version 시작 라인 요청 메시지 - HTTP 메서드 종류 : GET, POST, PUT, DELETE... 서버가 수행해야 할 동작 지정 GET: 리소스 조회 POST: 요청 내역 처리 GET /search?q=..

tcp / ip 같은 경우에는 기본적으로 연결을 유지하게 된다. 연결을 유지하는 동안 서버에 자원이 계속 소모가 된다. 연결을 유지하지 않는 모델은 자원을 요청을 주고 받을 때만 연결을 하고 끊어버려서 서버가 유지하는 자원을 최소한으로 줄이는 것이다. 서버가 동시에 유지해야 되는 자원은 요청할 때만 받고 바로 끊어버리기 때문에 최소한의 자원으로 서버를 유지할 수 있다. 비 연결성 HTTP는 기본이 연결을 유지하지 않는 모델 일반적으로 초 단위 이하의 빠른 속도로 응답 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하이고 매우 작다. ex) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지 않음 서버 자원을 매우 효율적으로 사용 가능(자원의 가용성을 높일 수 있음) ..

무상태 프로토콜 스테이스리스(Stateless) 서버가 클라이언트의 상태를 보존 X 장점 : 서버 확장성 높음(스케일 아웃) 단점: 클라이언트가 추가 데이터 전송 Stateful, Stateless 차이 정리 상태 유지: 중간에 다른 점원으로 바뀌면 안됨.(중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 함) 무상태: 중간에 다른 점원으로 바껴도 된다. 갑자기 고객이 증가해서 점원을 대거 투입할 수 있다. 클라이언트 요청이 증가해도 서버를 대거 투입 할 수 있다. 무상태는 응답 서버를 쉽게 바꿀 수 있다. => 무한한 서버 증설 가능 아래 그림을 보면 stateful에서는 서버를 늘리기가 어렵다. 서버1(점원 A)와 계속 통신을 해야하기 때문이다. 갑자기 서버1번이 장애가 나면? ..

HTTP 메시지에 모든 것을 전송 HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) 거의 모든 형태의 데이터 전송 가능 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용 HTTP 역사 HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X HTTP/1.0 1996년: 메서드, 헤더 추가 HTTP/1.1 1997년: 가장 많이 사용, 가장 중요한 버전 (RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)) HTTP / 2 2015년: 성능 개선 HTTP / 3 진행중: TCP 대신에 UDP 사용, 성능 개선 기반 프로토콜 TCP: HTTP / 1.1, HTTP / 2 UDP: HTTP / 3 현재 HTTP/1...

HTTP 요청 메시지는 아래와 같이 생겼다. 두번째 부분보면 SOCKET 라이브러리를 통해서 OS TCP / IP 계층에 전달을 해준다.( SYN, SYN / ACK, ACK) 전송데이터는 웹브라우저가 만든 HTTP 메세지이다. 인터넷 망으로 던지면 수많은 인터넷 노드를 통해서 200.200.200.2로 전달이 된다. 요청 패킷이 도착하면 구글 서버가 TCP/IP 패킷을 다까서 버리고 HTTP 메시지를 해석을 한다. (query가 hello이고 search로 왔고 hl와 관련된 ko로 해서 데이터를 찾는다. 다음 구글 서버에서 HTTP 응답 메시지를 만들어 낸다. Content-Type은 데이터부가 html형식이다라고 언어는 UTF-8로 charset이 되어있다 정보를 넘긴다. 실제 html의 길이는 C..

URI 리소스를 식별하는 통합된 방법 "URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다." 참고 : https://www.ietf.org/rfc/rfc3986.txt URL(리소스의 위치) / URN(리소스의 이름) urn은 이름을 부여한다.(리소스 찾기 어려움) - 거의 url만 쓴다. URI Uniform: 리소스 식별하는 통일된 방식 Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음) Identifier: 다른 항목과 구분하는데 필요한 정보 URL : Uniform Resource Locator URN: Uniform Resource Name URL, URn URL - Locator : 리소스가 있는 위치를 지정 URN - Name: 리소..

port 한 pc가 여러 개의 서버랑 통신을 하는데 각 패킷이 게임에서 필요한 건지 화상통화에 필요한 건지 웹 브라우저에 필요한 건지 알 수가 없다. 그래서 tcp port를 보면 출발지 port 목적지 port 개념이 있는데 ip는 목적지 서버를 찾는것 / 포트는 서버안에 애플리케이션을 구분하는 역할 아래와 같은 형식으로 tcp/ip 패킷이 구분되있다. 서버에서 클라이언트의 포트까지 알 수가 있는데 패킷을 보낼 때 출발지 ip랑 port까지 다 보내서 알 수 있다. ip가 아파트라 생각하고 port는 몇 동 몇호 이것이 port의 개념이라 생각하자. PORT 0 ~ 65535 할당 가능 0 ~ 1023 : 잘 알려진 포트, 사용하지 않는 것이 좋다. FTP - 20, 21 TELNET - 23 HTT..