HTTP 메시지

HTTP · 27 Oct 2022

해당 내용은 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 수강하여 작성했습니다.

HTTP 메시지 구조

HTTP 요청을 주고 받을 때 사용하는 메시지로서, 크게 start-line, header, empty line, message body로 나뉩니다. HTTP 메시지는 단순하게 이루어져있다는 특징 때문에, 확장에 용이하다는 장점이 있습니다.

start-line

메시지 구조의 가장 윗 부분으로, request-line과 status-line으로 구분됩니다.
request-line
- method SP(공백) request-target(요청 대상) SP HTTP-version CRLF(엔터)
- ‘method’라는 것을 가지며, 이는 서버가 수행해야 할 동작을 지정합니다.
  - GET : 리소스 조회
  - POST : 요청 내역 처리
  - request-target : 절대경로(”/”로 시작하는 경로)
status-line
- HTTP-version SP status-code SP reason-phrase CRLF의 형태를 가집니다.

header-field = field-name “:” OWS field-value OWS(띄워쓰기 허용)
대소문자의 구분이 없습니다.
HTTP 전송에 필요한 모든 부가정보를 담고 있습니다.
메시지의 크기, 압축, 인증, 클라이언트 정보, 캐시 관리 정보 등이 담깁니다.
필요 시 임의 헤더를 추가할 수 있습니다.

message body

실제 전송할 데이터를 담는 곳으로, HTML 문서, 이미지, 영상, JSON 등의 데이터들이 들어갑니다.

HTTP API 생성 시 주의점

API URI를 만들 때 가장 중요한 것은 ‘리소스 식별’입니다. 예를 들어, ‘회원을 조회’ 하는 것이 리소스가 아니라 ‘회원’ 자체가 리소스이기 때문에, URI에 ‘회원’ 리소스를 연결해주어야 합니다.

즉, 리소스와 행위를 분리하는 것이 중요하며, 아래와 같이 분리를 해줄 수 있습니다. 여기서 행위는 메서드로 구분합니다.

리소스 : 회원
행위 : 조회, 등록, 삭제, 변경

HTTP 메서드

HTTP 메서드는 크게 아래와 같은 종류로 나뉩니다.

GET : 조회
POST : 요청 데이터 처리, 주로 등록에 사용
PUT : 리소스를 대체, 해당 리소스가 없으면 생성
PATCH : 리소스 부분 변경
DELETE : 리소스 삭제
HEAD : GET과 동일하나 메시지를 제외한 것만 보냄
그 외에 OPTIONS, CONNECT, TRACE 등

GET

리소스를 조회할 때 사용하는 메서드입니다. 서버에 전달하고 싶은 데이터가 있을 시 ‘query’를 통해 전달하게 되며, 이외에도 ‘message body’를 통해서 전달이 가능하나 권장되지 않습니다.

POST

클라이언트가 메시지 바디로 보낸 요청 데이터를 통해 처리하며, 전달된 데이터를 ‘신규 리소스 등록,’ ‘프로세스 처리’에 사용합니다. 주로 새 리소스를 생성하거나 요청 데이터 처리를 통해 서버에서 큰 변화를 발생시킵니다.

대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하는 형식으로 요청 데이터를 처리합니다. POST를 사용하는 예시로는 ‘HTML form에서의 입력 양식’, ‘글쓰기, 댓글 달기’, ‘신규 회원 생성’ 등이 있습니다.

메시지를 담는 모든 것을 할 수 있기 때문에, 다른 메서드로 처리가 어려운 경우에도 사용하게 됩니다.

PUT

리소스를 ‘완전히’ 대체하는 작업을 하며, 리소스가 없다면 새롭게 리소스를 생성합니다. 특히, POST와의 차이점으로, 클라이언트가 리소스의 위치를 알고 URI를 지정합니다.

리소스를 완전히 대체하기 때문에 기존 정보 중 다른 필드도 모두 삭제됩니다. 그래서 PUT은 수정을 위한 용도로 사용되지는 않습니다.

PATCH

리소스의 부분 변경 시 사용하게 됩니다. 기존에 저장된 내용 중 같은 필드의 내용만 바꾸게 되고, 나머지 내용은 남겨둡니다. 리소스 부분 변경 시 PATCH가 안되는 경우에는 POST를 사용하면 됩니다.

DELETE

리소스를 제거할 때 사용합니다.

HTTP 메서드의 속성

안전

호출해도 리소스가 변경되지 않는 것을 의미합니다. 예를 들어, GET의 경우 조회만 하기 때문에 ‘안전’하고, POST, PUT 등은 변경이 발생하기 때문에 안전하지 않다고 볼 수 있습니다. 안전에 대해 이야기할 때 해당 리소스에 대해서만 고려하고 로그는 따지지 않습니다.
멱등 (Idempotent)

재요청 중간에 다른 곳에서 리소스를 바꾸는 상황에 대해서는 고려하지 않고, 몇 번을 호출하든 결과가 똑같은 것을 의미합니다. GET, PUT, DELETE가 멱등하고, POST는 그렇지 않다고 볼 수 있는데, 그 이유는 아래와 같습니다.
- PUT에서 같은 것을 업로드하는 경우 계속 같은 결과가 나오기 때문에 멱등함
- DELETE에서 몇 번을 호출하든 계속 같은 리소스를 삭제함
- POST는 멱등하지 않음 → 결제를 두 번 하게 되면 중복 결제가 발생함
멱등을 활용할 수 있는 방법으로는 다시 실행해도 되는 것들이 있으며, 자동 복구 메커니즘이 그 예시가 될 수 있습니다. 실패한 요청에 대해 클라이언트가 다시 요청을 보내도 되는 지를 판단하여 활용해야 합니다.
캐시 가능 (Casheable)

응답 결과 리소스를 캐시해서 사용해도 되는가를 의미합니다. GET, HEAD, POST, PATCH가 여기에 속합니다. 그러나 보통 실제로는 GET, HEAD만 사용하며, POST, PATCH는 본문 내용까지 캐시 키로 고려해야하기 때문에 구현이 어렵습니다.