developer h1 developer h1

HTTP 메서드의 속성 - 안전 (Safe Methods) - 멱등 (Idempotent Methods) - 캐시가능 (Cacheable Methods) 안전 - 호출해도 리소스를 변경하지 않는다 - 로그가 쌓여서 장애가 나는 등의 장애까지는 고려하지 않는다 멱등 - f(f(X)) = f(x) - 몇번 호출하더라도 결과가 똑같다 - 멱등 메서드 - GET : 한 번 조회하든, 두번 조회하든 같은 결과가 조회된다 - PUT : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다 - DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제되니 결과는 똑같다 - POST : 멱등이 아니다. 두번 호출하면 같은 결제가 중복해서 발생할 수 있다 // 하나의 리소스로 호출을 반복해도 결과가 ..

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

API URI 설계 요구사항 : 회원 정보 관리 API를 만들어라 - 회원 목록 조회 / read-member-list - 회원 조회 / read-member-by-id - 회원 등록 / create-member - 회원 수정 / update-member - 회원 삭제 / delete-member 이것은 좋은 URI 설계일까? 가장 중요한 것은 리소스 식별이다 리소스의 의미는 뭘까? - 회원을 등록하고 수정하고 조회하는게 리소스가 아니다 - 예) 미네랄을 캐라 > 미네랄이 리소스 - 회원이라는 개념 자체가 바로 리소스이다 리소스를 어떻게 식별하는게 좋을까? - 회원을 등록하고 수정하고 조회하는 것을 모두 배제 - 회원이라는 리소스만 식별하면 된다 > 회원 리소스를 URI에 매핑 위 지식을 동원해 다시 설..

이전에 웹 브라우저 카테고리에서 HTTP 메시지에 대한 내용을 조금 언급했다 이번엔 그것에 대해 조금 더 깊게 이해 해보자 HTTP 요청 메시지와 HTTP 응답 메시지의 구조는 동일하다 start-line 시작라인 header 헤더 empty line 공백라인 message body 바디 전에 언급한 HTTP 요청 메시지에서는 바디가 없었다 -GET /search?q=hello&hi=ko HTTP/1.1 (시작라인) HOST: http://www.google.com(헤더) (empty line) 딱히 전송할 데이터가 없을 때 이렇게 생략할 수 있으며, 요청 메시지도 body를 가질 수 있다 응답 메시지는 이렇게 생겼다 HTTP/1.1 200 OK (시작라인) Content-Type: text/html;c..

TCP/IP 는 기본적으로 연결을 유지한다 클라이언트 1,2,3 이 한 서버에 연결을 하고 있을 때, 당장 사용하지 않는 클라이언트 조차 연결을 유지하기 때문에, 서버 자원이 소모된다 연결을 유지하지 않는 모델은 요청 - 응답 이후 연결을 끊는다 최소한의 자원만 유지할 수 있게 된다 - HTTP는 기본적으로 연결을 유지하지 않는 모델 - 일반적으로 초 단위 이하의 빠른 속도로 응답 - 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다 -예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다 - 서버 자원을 매우 효율적으로 사용할 수 있음 비 연결성의 한계와 극복 - TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가 ..

무상태 프로토콜 (Stateless) - 서버가 클라이언트의 상태를 보존하지 않음 - 장점 : 서버 확장성 높음 (스케일 아웃 - 수평 확장 유리) - 단점 : 클라이언트가 추가 데이터 전송 Stateful(상태 유지), Stateless 차이 Stateful 은 이전의 상태를 보존하여 현재 요청과 이어진다 Stateless 는 이전의 상태를 보존하지 않아 이전 요청과 현재 요청이 이어지지 않는다 이걸 고객과 점원의 입장으로 비유하면 아래와 같다 상태 유지 : 중간에 다른 점원으로 바뀌면 안된다 (바뀐다면 다른 점원에게 상태정보를 미리 알려준다) 무상태 : 중간에 다른 점원으로 바뀌어도 된다 - 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다 - 갑자기 클라이언트의 요청이 증가해도 서버를 대거 투입할..

HTTP (HyperText Transfer Protocol) 원래는 HTML 을 전송하는 프로토콜로 시작이 됐다 지금은 모든 것을 HTTP 메시지에 담아서 전송한다 - HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML(API) 등등... - 거의 모든 형태의 데이터 전송 가능 - 서버간의 데이터를 주고 받을 때도 대부분 HTTP 사용 1997년에 나온 HTTP/1.1 이 가장 중요한 버전이다 2015년에 나온 HTTP/2 는 성능 개선에 초점을 맞췄고, 현재 진행중인 HTTP/3 는 성능 개선과 함께 TCP 대신에 UDP 사용 잘 정리는 안되지만 기능적인 변경점이 없기에 1.1버전을 중심으로 공부를 하면 된다고 한다 기반 프로토콜 - TCP : HTTP/1.1, HTTP/2 - ..

주소창에 이전에 알아본 URL 양식에 맞게 작성하면 어떻게 동작할까 1.먼저 DNS를 조회하여 IP, PORT를 찾아내고, HTTP 요청 메시지를 생성한다 -HTTP 요청 메시지는 이렇게 생겼다 -GET /search?q=hello&hi=ko HTTP/1.1 HOST: http://www.google.com 2. 인터넷 프로토콜 스택의 4계층(TCP카테고리 참고)을 거쳐 HTTP 메시지를 전송한다 - 이전에 '전송 데이터' 라고 표현했던 것이 바로 이 HTTP 메시지이다 3. 서버는 패킷을 버리고 HTTP 메시지를 읽어 HTTP 응답 메시지를 생성한다 - HTTP 응답 메시지는 또 다르게 생겼는데, 요약하면 HTTP 버전, 응답할 언어(HTML), 응답 메시지의 길이, 해당 언어로 작성된 메시지 본문 정..