[API] HTTP 메서드 종류와 특징
HTTP는 웹에서 클라이언트와 서버 간 데이터 통신을 관리하는 프로토콜로, API 설계에서 매우 중요한 역할을 합니다. HTTP 메서드는 이러한 통신의 구체적인 동작 방식을 정의하며, 각 메서드는 고유한 목적과 특성을 가지고 있습니다. 이번 글에서는 주요 HTTP 메서드에 대해 자세히 살펴보겠습니다.
GET
GET 메서드는 서버에서 데이터를 요청하고 조회할 때 사용됩니다. 웹에서 가장 많이 사용되는 메서드로, URL을 통해 특정 리소스를 요청합니다.
주요 특징
안전성(Safe)
GET 요청은 서버의 상태를 변경하지 않습니다. 단순히 데이터를 조회할 때 사용되므로, 서버에 부작용을 일으키지 않는다고 간주됩니다.
멱등성(Idempotent)
동일한 GET 요청을 여러 번 보내더라도 결과는 변하지 않습니다. 예를 들어, 같은 페이지를 여러 번 로드해도 페이지 내용이 달라지지 않습니다.
캐싱 가능(Cacheable)
GET 요청은 서버로부터 받은 데이터를 캐싱할 수 있습니다. 브라우저나 프록시 서버에서 캐싱된 데이터를 사용함으로써 성능을 최적화할 수 있습니다.
요청 본문 없음
GET 요청은 일반적으로 본문을 포함하지 않으며, 모든 정보는 URL에 쿼리 문자열의 형태로 전달됩니다.
사용 사례
- 웹 페이지 로드
- 데이터 조회 (예: 블로그 게시물 보기, 상품 목록 조회)
- 검색 기능 구현 (쿼리 문자열을 통한 검색)
POST
POST 메서드는 서버로 데이터를 전송하여 새로운 리소스를 생성하거나 데이터를 처리할 때 사용됩니다. 폼 데이터를 제출하거나 파일을 업로드하는 등, 서버에 어떤 작업을 요청할 때 주로 사용됩니다.
주요 특징
안전성 없음
POST 요청은 서버의 상태를 변경할 수 있습니다. 예를 들어, 데이터베이스에 새로운 항목을 추가하거나, 서버에서 어떤 처리를 수행할 때 사용됩니다.
멱등성 없음
동일한 POST 요청을 여러 번 보내면, 서버에서 동일한 작업이 여러 번 수행될 수 있습니다. 예를 들어, 주문 요청을 여러 번 보내면 동일한 주문이 여러 번 처리될 수 있습니다.
캐싱 불가
POST 요청은 일반적으로 캐싱되지 않습니다. 왜냐하면 POST는 서버 상태를 변경하는 요청이기 때문에, 캐싱을 통해 같은 응답을 재사용하면 안 되기 때문입니다.
요청 본문 포함
POST 요청은 데이터를 요청 본문에 포함하여 서버로 전송합니다. 이는 파일 업로드, JSON 데이터 전송, 폼 데이터 제출 등 다양한 형태로 이루어질 수 있습니다.
사용 사례
- 사용자 등록
- 댓글 작성
- 서버에 데이터 처리 요청 (예: 계산 요청, 검색 요청)
PUT
PUT 메서드는 서버에 있는 리소스를 전체적으로 업데이트하거나, 지정된 URI에 리소스가 없을 경우 새로운 리소스를 생성할 때 사용됩니다. PUT 요청은 리소스의 전체 상태를 교체하는 역할을 합니다.
주요 특징
멱등성
동일한 PUT 요청을 여러 번 보내도 결과는 동일합니다. 서버의 특정 리소스를 동일한 데이터로 여러 번 덮어써도 최종 상태는 변하지 않습니다.
전체 교체
PUT 요청은 리소스의 전체 데이터를 요구합니다. 요청 본문에 모든 필드를 포함해야 하며, 누락된 필드는 기본값으로 대체되거나 삭제될 수 있습니다.
캐싱 가능
PUT 요청은 일반적으로 캐싱되지 않지만, HTTP 명세상으로는 캐싱 가능으로 지정할 수 있습니다.
사용 사례
- 사용자 프로필 업데이트 (전체 프로필 정보 교체)
- 특정 리소스의 상태 변경 (예: 특정 주문의 상태를 “처리됨”으로 변경)
PATCH
PATCH 메서드는 리소스의 일부를 업데이트할 때 사용됩니다. PUT과 달리, PATCH는 리소스의 일부만 변경할 수 있습니다. 이 메서드는 주로 리소스의 특정 필드를 수정할 때 사용됩니다.
주요 특징
멱등성
PATCH 요청도 멱등성을 가질 수 있지만, 구현에 따라 달라질 수 있습니다. 동일한 PATCH 요청을 여러 번 보내면, 동일한 결과를 얻어야 합니다.
부분 수정
PATCH는 리소스의 전체 교체가 아닌, 일부 필드만을 수정합니다. 예를 들어, 사용자 프로필에서 이메일 주소만 수정할 수 있습니다.
캐싱 불가
PATCH 요청은 일반적으로 캐싱되지 않습니다.
사용 사례
- 사용자 프로필의 특정 필드 업데이트 (예: 이메일 주소만 변경)
- 주문의 일부 상태 변경 (예: 배송 정보만 수정)
DELETE
DELETE 메서드는 서버에서 특정 리소스를 삭제할 때 사용됩니다. 주어진 URI에 해당하는 리소스를 삭제하는 요청입니다.
주요 특징
멱등성
동일한 DELETE 요청을 여러 번 보내더라도 결과는 동일합니다. 리소스가 이미 삭제된 경우, 추가적인 삭제 작업은 발생하지 않습니다.
안전성 없음
DELETE 요청은 서버의 상태를 변경합니다. 이는 데이터를 영구적으로 삭제하는 작업이므로, 중요한 변경 사항입니다.
캐싱 불가
DELETE 요청은 일반적으로 캐싱되지 않습니다.
사용 사례
- 사용자 계정 삭제
- 게시물 삭제
- 파일 또는 데이터 레코드 삭제
HEAD
HEAD 메서드는 GET 요청과 유사하지만, 서버에서 응답 본문을 포함하지 않고, 응답 헤더만 반환합니다. 클라이언트는 리소스의 메타데이터를 확인하기 위해 HEAD 요청을 사용할 수 있습니다.
주요 특징
안전성
HEAD 요청은 서버의 상태를 변경하지 않으므로 안전합니다.
멱등성
동일한 HEAD 요청을 여러 번 보내더라도 결과는 동일합니다.
본문 없음
HEAD 요청은 응답 본문을 포함하지 않으며, 오직 헤더 정보만 반환됩니다. 이 정보는 리소스의 존재 여부나 마지막 수정 시간, 크기 등을 포함할 수 있습니다.
사용 사례
- 리소스의 존재 여부 확인 (예: 파일이 서버에 있는지 확인)
- 리소스의 메타데이터 확인 (예: 마지막 수정 시간, 크기)
OPTIONS
OPTIONS 메서드는 서버에서 특정 리소스에 대해 지원하는 HTTP 메서드를 확인하는 데 사용됩니다. 서버는 요청에 대해 가능한 메서드 목록을 반환합니다.
주요 특징
안전성
OPTIONS 요청은 서버의 상태를 변경하지 않으므로 안전합니다.
멱등성
동일한 OPTIONS 요청을 여러 번 보내더라도 결과는 동일합니다.
CORS 처리
OPTIONS는 주로 CORS(Cross-Origin Resource Sharing)에서 프리플라이트 요청으로 사용되어, 클라이언트가 특정 리소스에 대해 허용된 메서드와 헤더를 확인할 수 있습니다.
사용 사례
- 지원되는 메서드 확인 (예: 서버가 GET, POST, PUT을 지원하는지 확인)
- CORS 프리플라이트 요청 (예: 다른 도메인에서의 요청을 허용하는지 확인)
TRACE
TRACE 메서드는 클라이언트가 요청이 서버까지 전달되는 경로를 추적할 때 사용됩니다. 이 메서드는 주로 디버깅 목적으로 사용되며, 요청이 중간 서버나 프록시를 거쳐 어떤 경로로 전달되었는지 확인할 수 있습니다.
주요 특징
안전성 없음
TRACE 요청은 서버 상태를 변경하지 않지만, 보안상의 이유로 많은 서버에서 비활성화되어 있습니다. 클라이언트가 보낸 요청을 그대로 반환하므로, 공격자가 악용할 수 있는 취약점이 될 수 있습니다.
디버깅 목적
TRACE는 주로 네트워크 경로를 확인하거나 요청이 제대로 전달되는지 확인하는 데 사용됩니다.
사용 사례
- 요청 경로 디버깅
- 프록시 서버나 방화벽 설정 확인
읽어주셔서 감사합니다. 😊
Reference
ChatGPT - OpenAI