Dev

PUT 리소스가 있으면 완전히 대체해줌 리소스가 없으면 생성해줌 쉽게 이야기해서 덮어버리는 메서드 중요! 클라이언트가 리소스를 식별 클라이언트가 구체적인 리소스 전체 위치를 알고 URI를 지정한다 (이게 POST와의 차이) PUT은 사실 리소스를 수정하는것보다 리소스를 완전히 갈아치우기 때문에 리소스 수정에는 적합하지 않다. 수정 의도로 사용하려면 PATCH를 사용해야한다. (PUT 후에 PATCH가 새로나옴) PATCH PATCH는 age만 부분변경 가능하다 DELETE 리소스제거

HTTP 메서드란? 클라이언트가 서버에 요청할때 기대하는 행동 HTTP 메서드 종류 주요 메서드 GET : 리소스 조회 POST : 요청 데이터 처리, 주로 등록에 사용 PUT : 리소스를 대체, 해당 리소스가 없으면 생성 PATCH : 리소스 부분 변경 DELETE : 리소스 삭제 기타 메서드 HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환 OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명 (주로 CORS에서 사용) CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정 (거의 사용안함) TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 (거의 사용안함) GET GET/search?q=hello&hi=KO HTTP/..

이게 좋은 URI 설계일까? 실제로 현업에서 이렇게 많이 설계한다. URI의 가장 중요한건 리소스다. API URI 고민 URI(Uniform Resource Identifier) 리소스의 의미는 뭘까? 회원을 등록하고 수정하고 조회하는게 리소스가 아니다! 예) 미네랄을 캐라 -> 미네랄이 리소스 회원이라는 개념 자체가 바로 리소스다. 리소스를 어떻게 식별하는게 좋을까? 회원을 등록하고 수정하고 조회하는 것을 모두 배제. 회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑 리소스와 행위을 분리 가장 중요한 것은 리소스를 식별하는 것 URI는 리소스만 식별! 리소스와 해당 리소스를 대상으로 하는 행위를 분리 - 리소스: 회원 - 행위: 조회, 등록, 삭제, 변경 (GET, POST, DE..

HTTP는 요청, 응답 메시지 구조가 다르다 HTTP 메시지 구조는 시작라인, 헤더, 공백라인, 메시지 Body 시작라인 요청 메시지 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: 요청 내역 처리 시작 라인 요청 메시지 - 요청 대상 absolute-path[?query] (절대경로[?쿼..

TCP/IP요청을 보내고 응답을 받으면 연결이 유지된다. 클라이언트3까지 요청, 응답 받는동안 클라 1, 2도 연결되어 서버에 자원이 소모되고 있다. 클라 1, 2가 놀고있어도 서버가 연결을 계속 유지해야하는 단점이있다 이렇게하면 서버 입장에서 서버 유지 자원을 최소한으로 줄이는 장점이있다. 클라가 수만대라 생각하면 엄청난 자원을 save하는것이다. 비연결성 HTTP는 기본이 연결을 유지하지 않는 모델이다 일반적으로 초 단위 이하의 빠른 속도로 응답한다. 요청, 응답이 몇초에 끝난다. 1시간동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다 (예 : 웹 브라우저에세 계속 연속해서 검색 버튼을 누르지는 않는다) 서버 자원을 매우 효율적으로 사용할 수 있다. 비연결..

클라이언트 서버 구조 Request, Response (요청, 응답) 구조 클라이언트는 서버에 요청을 보내고, 응답을 대기한다. 서버가 요청에 대한 결과를 만들어서 응답해주고 응답값으로 클라이언트는 UI를 그린다 무상태 프로토콜 스테이스 리스 (Stateless) 서버가 클라이언트의 상태를 보존하지 않음 장점 : 서버 확장성 높음 (스케일 아웃) 단점 : 클라이언트가 추가 데이터 전송 Stateful, Stateless 차이 상태 유지 - Stateful Stateful, Stateless 차이 상태 유지 - Stateful, 점원이 중간에 바뀌면? Stateful, Stateless 차이 상태 유지 - Stateful, 정리 Stateful, Stateless 차이 무상태 - Stateless 포인트 ..

HTTP (HyperText Transfer Protocol) HTML, TEXTImage, 음성, 영상, 파일JSON, XML (API)거의 모든 형태의 데이터 전송 가능서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용HTTP 의 역사HTTP/0.9 1991년 : Get 메서드만 지원, HTTP 헤더 없음HTTP/1.0 1996년 : 메서드, 헤더 추가HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전→ 이 스펙에 대부분의 기능이 다 들어있고 2, 3 버전은 거의 성능개선에만 초점이 맞춰져 있음HTTP/2 2015년 : 성능 개선HTTP/3 진행중 : TCP 대신에 UDP사용, 성능 개선 기반 프로토콜 TCP : HTTP/1.1, HTTP/2UDP : HTTP/3현재 HTT..

웹브라우저가 http 메시지를 생성 소켓 라이브러리를 통해서 OS계층의 TCP/IP에 전달 패킷을 한번 씌우고 패킷 정보가 인터넷에 흘러감 이렇게해서 요청패킷을 인터넷망으로 던짐 요청 패킷이 도착하면 구글서버가 TCP/IP 패킷을 다 까서 버리고 http메시지를 끄집어내고 해석함 그런 다음에 http 응답 메시지를 만들어냄 Content-Type : 이건 데이터가 html형식, 언어는 UTF-8 Content-length: html파일의 길이 이런 응답메시지가 다시 클라이언트에게 오면 클라이언트는 요청한 화면의 페이지를 볼 수 있음

URI (Uniform Resource Identifier) URI? URL? URN? URI 는 로케이터 (locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다 URI 단어 뜻 Uniform : 리소스 식별하는 통일된 방식 Resource : 자원, URI로 식별할 수 있는 모든 것 (제한 없음) Identifier : 다른 항목과 구분하는데 필요한 정보 URL : Uniform Resource Locator URN : Uniform Resource Name URL, URN 단어 뜻 URL - Locator : 리소스가 있는 위치를 지정 URN - Name : 리소스에 이름을 부여 위치는 변할 수 있지만, 이름은 변하지 않는다. 이름은 안변하니까 좋을거같은데 예 : urn:isbn:89..

이런 단점 때문에 DNS 사용 DNS 도메인 네임 시스템 (Domain Name System) 전화번호부 같은 시스템 도메인 명을 IP 주소로 반환 인터넷 네트워크 정리 인터넷 통신 IP (Internet Protocol) TCP, UDP PORT DNS IP만으로는 메시지 잘 도착했는지 신뢰도 어렵고 순서도 꼬일수 있음 이런 문제를 TCP가 해결 UDP는 PORT 정보만 추가되는 거의 백지상태 PORT는 같은 IP안에서 동작하는 애플리케이션 구분을 위해 사용 아파트가 IP 면 몇동, 몇호는 PORT IP가 변하기쉽고 외우기 어려운데 도메인명을 등록해서 사용할수 있도록 해주는게 DNS