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 메서드는 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는 주로 네트워크 경로를 확인하거나 요청이 제대로 전달되는지 확인하는 데 사용됩니다.

사용 사례

  • 요청 경로 디버깅
  • 프록시 서버나 방화벽 설정 확인