HTML과 같은 문서를 전송하기 위한 애플리케이션 레이어 프로토콜입니다.
HTTP는 웹 브라우저와 웹 서버의 소통을 위해 디자인 되었습니다.
몇 줄의 텍스트 정보로 구성된 메시지로 클라이언트와 서버사이에서 데이터가 교환되는 방식.
요청 (Request)
클라이언트가 서버에 보내는 메시지
응답 (Response)
서버가 클라이언트에 보내는 메시지
요청과 응답은 다음과 같은 유사한 구조를 가집니다.
start line (응답에서는 status line)
요청이나 응답의 상태를 나타낸다.
HTTP headers
요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합이다.
참고 게시글 : HTTP 헤더
empty line
Header와 Body를 구분한다.
body
메시지와 관련된 데이터 또는 문서를 포함하며, 선택적으로 사용한다.
start line과 headers를 묶어서 head라고 하며, payload는 body라고 한다.
요청의 Start line은 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타낸다.
GET
서버에서 데이터를 가져옵니다. 다른 효과가 없어야 합니다.
PUT
대상 리소스를 요청 페이로드로 바꿉니다. 새 리소스를 업데이트하거나 생성하는 데 사용할 수 있습니다.
PATCH
PUT과 유사하지만 기존 리소스 내의 특정 필드만 업데이트하는 데 사용됩니다.
POST
페이로드에서 리소스별 처리를 수행합니다. 새 리소스 만들기, 파일 업로드 또는 웹 양식 제출을 비롯한 다양한 작업에 사용할 수 있습니다.
DELETE
서버에서 데이터를 제거합니다.
TRACE
서버가 수신하는 내용을 테스트하는 방법을 제공합니다. 단순히 보낸 것을 반환합니다.
OPTIONS
클라이언트가 서비스에서 지원하는 요청 방법에 대한 정보를 얻을 수 있도록 합니다. 관련 응답 헤더는 지원되는 방법으로 허용입니다. 또한 CORS에서 실제 요청 방법에 대해 서버에 알리고 사용자 정의 헤더에 대해 묻기 위한 비행 전 요청으로 사용됩니다.
HEAD
응답 헤더만 반환합니다.
CONNECT
브라우저가 프록시와 통신하고 최종 URI가 https:// 로 시작하는 것을 알고 있을 때 사용합니다. CONNECT의 목적은 종단 간 암호화된 TLS 세션을 허용하여 프록시에서 데이터를 읽을 수 없도록 하는 것입니다.
POST+Preflight ?
요청의 Headers는 기본 구조를 따릅니다. (기본구조 = 헤더명: 값
)
요청의 Body는 마지막에 위치하며, 모든 요청에 필요로하지 않는다.
GET, HEAD, DELETE, OPTIONS 처럼 서버에 리소스를 요청하는 경우는 불필요.
POST, PUT 과 같은 일부 요청은 데이터를 전달하기 위해 사용.
응답의 Status line은 요청의 결과(Code)와 설명을 나타낸다.
ex) HTTP/1.1 404 Not Found.
응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조를 가지고 있다.
Response headers
위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 제공한다.
General headers (= 요청과 설명이 같음)
Entity headers (= 요청과 설명이 같음)
모든 응답에 Body가 필요한건 아니다.
(201, 204와 같은 상태코드는 Body를 사용하지 않는다.)
HTTP는 특정 상태를 담고 있지 않으며, 이전 요청이나 다음 요청을 기억하지 않습니다.
클라이언트나 서버에서 발생한 모든 상태를 HTTP 통신이 추적하지 않습니다.
HTTP는 통신 규약일뿐, 상태를 저장하지 않으며 필요에 따라 다른 방법을 통해 상태를 확인해야 합니다. (상태 저장 = 쿠키, 세션, API)