HTTP 메서드 완벽 가이드 GET, POST, PUT, PATCH, DELETE 등 총정리

HTTP란 무엇인가?

HTTP(Hypertext Transfer Protocol)는 웹에서 데이터를 주고받기 위해 사용하는 응용 계층 프로토콜입니다. 우리가 브라우저에서 URL을 입력하거나, REST API 서버에 요청을 보낼 때, 데이터를 요청하고 응답을 받는 방식이 모두 HTTP로 진행됩니다. 서버-클라이언트 모델을 기반으로 하고 있으며, 텍스트 기반의 요청(request)과 응답(response) 구조를 갖는 점이 특징입니다.

• Stateless(무상태성): 각 요청은 독립적으로 처리됩니다.
• 클라이언트-서버 모델: 클라이언트(브라우저, 앱 등)가 요청을 보내고 서버가 응답을 반환합니다.
• 텍스트 기반: 요청(Request)과 응답(Response)이 헤더와 본문(Body) 구조로 되어 있으며, 사람이 읽기에도 상대적으로 직관적인 형식입니다.

HTTP 메서드란?

HTTP 메서드(또는 HTTP Verb)는 클라이언트가 서버에 요청을 보낼 때 의도나 행동을 나타내는 중요한 요소입니다. 예를 들어 “어떤 자원을 조회할 것인가?” “자원을 생성할 것인가?” “삭제할 것인가?”와 같은 의도를 서버에 표현할 수 있습니다.

HTTP 요청은 다음과 같은 형식을 가집니다.

HTTP 메서드 + URL(요청 대상) + HTTP 버전
헤더(Header)
[빈 줄]
바디(Body) (필요 시)

• URL(Endpoint): 어떤 자원(리소스)에 접근할지를 지정
• HTTP 메서드(Verb): 그 자원에 대해 어떤 동작을 수행할지 지정

정확한 HTTP 메서드를 적절하게 사용하는 것은 RESTful API를 설계하거나, 일반적인 웹 애플리케이션을 구현할 때 매우 중요한 부분입니다.

HTTP 메서드의 분류 개념 (Safe, Idempotent, Cacheable)

1. Safe(안전 메서드)

Safe란 서버의 상태(데이터)를 변경하지 않는 메서드를 의미합니다. 즉, 요청을 여러 번 보내더라도 서버 자원에 영향을 주지 않아야 합니다.

• 대표적인 메서드: GET, HEAD, OPTIONS, TRACE
• Safe 메서드는 읽기(read) 전용이므로 외부에서 의도치 않게 변경되는 부작용이 없어야 합니다.

2. Idempotent(멱등 메서드)

Idempotent는 메서드를 여러 번 반복해서 호출했을 때, 그 결과가 언제나 동일하게 유지되는 성질을 말합니다.

• 대표적인 메서드: GET, PUT, DELETE, HEAD, OPTIONS, TRACE
• 예를 들어 PUT /resource/1에 어떤 데이터로 업데이트하는 요청을 여러 번 보내더라도 최종 결과는 동일해야 합니다.

단, POST는 보통 멱등성이 없는 것으로 간주합니다. 왜냐하면 같은 POST 요청을 여러 번 수행하면, 중복 데이터가 생성되거나 결과가 달라질 가능성이 크기 때문입니다.

3. Cacheable(캐싱 가능한 메서드)

HTTP에서 응답을 캐싱할 수 있는지 여부는 매우 중요한 성능 요소입니다. 원칙적으로 HTTP 표준에서 GET, HEAD, POST는 캐싱될 수 있습니다. 그러나 실제로 POST 결과를 캐싱하는 것은 컨트롤 헤더 설정과 구현에 따라 달라지기 때문에 흔하지는 않습니다. 보통 GET 응답만 캐싱을 고려하는 경우가 많습니다.

HTTP 주요 메서드 표로 한눈에 보기

아래 표는 대표적인 HTTP 메서드들의 특성과 사용 예시를 간단히 정리한 것입니다.

(위 표는 일반적인 경우를 정리한 것이며, 서버 구현에 따라 일부 특성이 달라질 수 있습니다.)

주요 HTTP 메서드 상세 정리

GET

• 의도: 서버에 존재하는 자원(Resource)을 조회할 때 사용
• 특징:
  • 서버 상태를 변경하지 않는 Safe 메서드
  • 멱등(Idempotent)
  • 캐싱(Cachable) 가능
  • 쿼리 파라미터를 통해 데이터를 전달하는 경우가 대부분(URI 뒤에 ?key=value 형태)
• 장점:
  • 매우 직관적이고, 브라우저에서 쉽게 테스트 가능
  • 링크 형태로 쉽게 공유 가능
• 주의사항:
  • URL에 특정 파라미터가 노출되므로 민감한 정보를 전달하기에는 부적절
  • 전송 데이터에 길이 제한이 있을 수 있음(서버마다 다르지만, 일반적으로 매우 긴 URL은 권장되지 않음)

GET /users?page=2&limit=10 HTTP/1.1
Host: api.example.com

이때 서버는 page=2에 해당하는 유저 목록 10개를 반환합니다.

POST

• 의도: 서버에 새로운 데이터를 생성하거나, 처리 요청을 할 때 주로 사용
• 특징:
  • 멱등성이 보장되지 않음(동일 요청 반복 시 중복 데이터 생성 가능)
  • 보통 요청 본문(Body)에 JSON, XML, Form-Data 등을 담아 전송
• 장점:
  • Request Body를 통해 대량의 데이터를 안전하게 전송 가능
  • 다양한 처리 로직(예: 결제, 메시지 전송 등)에 활용 가능
• 주의사항:
  • POST는 생성(Create)에 자주 쓰이지만, “업데이트”나 “처리”도 POST로 구현하는 경우가 많으므로 API 설계 시 메서드 정의를 명확히 하는 것이 좋다.

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "username": "new_user",
  "email": "new_user@example.com",
  "password": "123456"
}

이 요청으로 서버는 new_user라는 유저를 새로 생성합니다.

PUT

• 의도: 자원을 완전히 대체(전체 업데이트) 할 때 사용
• 특징:
  • 멱등(Idempotent)
  • 기존 자원이 없으면 새로 생성(서버 구현에 따라 달라질 수 있음)
  • 업데이트하고자 하는 자원 전체 데이터를 포함해야 함
• 장점:
  • 자원 전체를 교체해버리므로 요청 구조가 단순
  • 멱등성이 보장되어 에러 발생 시 재시도하기 편리
• 주의사항:
  • 부분 업데이트를 위해서는 PUT을 남용하지 않는 편이 낫다. (전체 데이터를 보내야 하므로 네트워크 비용 증가)
  • 기존에 존재하는 필드를 누락하면 해당 필드는 제거될 수 있음(서버 구현에 따라 다름)

PUT /users/100 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "username": "updated_user",
  "email": "updated_user@example.com",
  "password": "654321"
}

id = 100인 유저의 정보를 통째로 교체합니다.

PATCH

• 의도: 자원의 일부(부분)만 업데이트할 때 사용
• 특징:
  • 서버 상태 변경
  • 멱등성이 보장되지 않을 수도 있음(부분 업데이트 방식과 구현에 따라 달라질 수 있음)
  • 작은 변경사항만 전송하므로 네트워크 트래픽을 절감 가능
• 장점:
  • 대규모 자원을 전체 변경(PUT)하지 않고도 필요한 부분만 수정 가능
  • 성능적으로 효율적
• 주의사항:
  • 표준 스펙 상으로 PATCH의 요청 형식(특히 JSON Patch)은 다양한 방식이 존재. 서버 구현 시 표준 형식을 준수해야 서로의 의도를 명확하게 알 수 있다.

PATCH /users/100 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "email": "patch_email@example.com"
}

이 요청은 id = 100인 유저의 email 필드만 변경합니다.

DELETE

• 의도: 서버에 존재하는 자원을 삭제할 때 사용
• 특징:
  • 멱등(Idempotent)
  • 리소스가 이미 삭제된 상태에서 DELETE를 다시 호출해도 결과는 동일(삭제된 상태)
• 장점:
  • 자원 삭제 의도가 명확
• 주의사항:
  • 실제 데이터베이스에서 물리적으로 삭제하는 대신, 논리적 삭제(플래그로 표시)로 처리하기도 한다.
  • 클라이언트가 의도적으로 DELETE를 여러 번 요청해도 서버는 최종적으로 해당 자원이 없으면 OK로 처리할 수 있다.

DELETE /users/100 HTTP/1.1
Host: api.example.com

서버는 id=100인 유저를 삭제 처리합니다.

HEAD

• 의도: GET 요청과 동일한 응답 헤더를 가져오되, 메시지 본문(Body)은 받지 않음
• 특징:
  • Safe
  • 멱등(Idempotent)
  • 캐싱(Cachable)
• 용도:
  • 리소스의 크기, 수정 시각 등을 확인하기 위한 메타 정보 조회
  • 실제 콘텐츠를 다운로드하지 않고 빠른 검증을 위해 사용
• 주의사항:
  • 서버 구현에 따라 HEAD를 지원하지 않을 수도 있음(필수는 아님)

HEAD /images/photo.png HTTP/1.1
Host: example.com

이 요청의 응답은 Content-Length, Last-Modified 같은 헤더만 포함하고, 실제 이미지 데이터를 보내지 않습니다.

OPTIONS

• 의도: 특정 URL이 어떤 메서드와 옵션을 지원하는지 확인
• 특징:
  • Safe
  • 멱등(Idempotent)
• 용도:
  • 사전 요청(Preflight)으로 사용
  • CORS(Cross-Origin Resource Sharing)에서 브라우저가 실제 요청 전 미리 서버가 지원하는 메서드, 헤더 등을 확인할 때 자주 사용
• 주의사항:
  • 클라이언트 측에서 직접 보낼 일은 많지 않으나, 브라우저가 CORS 설정 시 자동으로 전송하는 예가 많음

OPTIONS /users HTTP/1.1
Host: api.example.com

서버는 이 URL에서 허용되는 메서드(GET, POST, PUT 등)를 헤더에 담아 응답합니다.

TRACE

• 의도: 요청을 루프백(Loopback) 테스트하기 위해 사용(디버깅 용도)
• 특징:
  • Safe
  • 멱등(Idempotent)
• 주의사항:
  • 대부분의 현대 웹 서버나 애플리케이션에서는 보안 취약점(예: XST 공격) 때문에 TRACE 메서드를 비활성화해둔 경우가 많음
  • 실제 운영 환경에서 사용할 일은 매우 드묾

CONNECT

• 의도: 프록시 서버가 TCP 터널을 설정할 때 사용
• 특징:
  • HTTPS 요청 시 프록시 서버를 통해 SSL 터널을 구성하기 위한 메서드
• 주의사항:
  • 일반적인 API 서버 사용 시 거의 쓰지 않는다.
  • 주로 프록시 관련 네트워크 수준에서 관리되며, 애플리케이션 로직에는 잘 등장하지 않음

부가적인 고려사항 (에러 핸들링, 응답 코드, RESTful 관점)

에러 핸들링 & 응답 코드

HTTP 메서드를 제대로 사용하려면 HTTP 응답 코드(상태 코드) 역시 상황에 맞게 설정해야 합니다.

• 200 OK: 요청 성공
• 201 Created: 새로운 자원 생성 시
• 204 No Content: 성공은 했으나 응답 본문이 없을 때(DELETE 후 성공 등의 경우)
• 400 Bad Request: 잘못된 요청
• 401 Unauthorized: 인증 필요
• 403 Forbidden: 권한 부족
• 404 Not Found: 자원 없음
• 405 Method Not Allowed: 해당 자원에 대해 메서드가 허용되지 않음
• 500 Internal Server Error: 서버 내부 에러

등을 적절히 사용해 주는 것이 좋습니다.

RESTful API 관점

RESTful API를 설계할 때 가장 기본이 되는 것이 리소스 설계와 HTTP 메서드 사용입니다.

• 리소스는 URL로 표현
• 행위는 메서드로 표현 예를 들어, 유저 정보를 조회하는 /users 엔드포인트가 있다면,
• 조회: GET /users, GET /users/:id
• 생성: POST /users
• 전체 업데이트: PUT /users/:id
• 부분 업데이트: PATCH /users/:id
• 삭제: DELETE /users/:id

이처럼 일관성 있게 설계하면, 클라이언트와 서버 간의 협업이 수월해집니다.

정리

HTTP 메서드는 웹 애플리케이션뿐 아니라 RESTful API 설계의 핵심 요소입니다. 단순히 GET, POST만 구분하는 것이 아닌, PUT, PATCH, DELETE, HEAD, OPTIONS 등 다양한 메서드의 의도와 성격을 정확히 이해하면 더욱 견고하고 직관적인 API를 구축할 수 있습니다.

• GET, HEAD: 읽기 전용, Safe, Idempotent
• POST: 자원 생성(멱등 아님)
• PUT: 자원 전체 업데이트(멱등)
• PATCH: 자원 일부 업데이트(멱등성은 구현에 따라 달라짐)
• DELETE: 자원 삭제(멱등)
• OPTIONS: 서버가 지원하는 메서드 확인
• TRACE, CONNECT: 디버깅, 터널링 등 특수 목적

궁극적으로 적절한 메서드를 올바른 상황에 배치하는 것은 서버-클라이언트 간 의도를 명확히 전달하며, 유지보수성, 확장성 측면에서도 큰 이점을 줍니다.

TIP: 실제 프로젝트에서는 문서화 도구(Swagger/OpenAPI 등)를 통해 API 엔드포인트별 메서드, 요청/응답 예시, 에러 코드 등을 상세히 정리해두면 협업과 유지보수에 큰 도움이 됩니다.

이상으로 HTTP 메서드에 대한 설명을 마칩니다.
앞으로 HTTP 기반의 서비스나 API를 구현할 때, 이 글이 참고가 되었길 바랍니다.