HTTP 요청 메서드란?

MDN - HTTP request methods
HTTP는 요청 메서드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타냅니다. 간혹 요청 메서드를 "HTTP 동사"라고 부르기도 합니다. 각각의 메서드는 서로 다른 의미를 구현하지만, 일부 기능은 메서드 집합 간에 서로 공유하기도 합니다. 이를테면 응답 메서드는 안전하거나, 캐시 가능하거나, 멱등성을 가질 수 있습니다.

HTTP는 요청 메서드(Method)를 통해 특정 리소스(URL)에 대해 수행하고자 하는 동작(의도, Semantics)을 표현한다.

HTTP 메서드는 클라이언트가 서버에게 "이 리소스에 대해 무엇을 하고 싶은지" 표현하는 방법이다.

그리고 HTTP 메서드에 세 가지 주요 특성이 있다.

• 안전성(Safe)
• 멱등성(Idempotent)
• 캐시 가능성(Cacheable)

Safe: 이 요청이 서버의 상태를 변경하지 않는다.
Idempotent: 같은 요청을 여러 번 보내도 서버의 최종 상태가 동일하다.
Cacheable: 결과를 저장해뒀다가 재사용할 수 있다.

---

Safe(안전성)이란?

Safe는 요청이 서버의 상태를 변경하지 않는 특성이다.
즉, 같은 요청을 몇 번 보내더라도 데이터 생성, 수정, 삭제와 같은 상태 변경이 발생하지 않아야 한다.

예를 들어 다음 요청은 사용자를 조회하는 요청이다.

GET /users/1

이 요청은 사용자의 정보를 조회할 뿐 데이터를 수정하지 않는다.

사용자 조회를 반복하더라도 서버의 상태는 변하지 않는다.
따라서 GET은 Safe한 메서드이다.

대표적인 Safe 메서드는 다음과 같다.

• GET
• HEAD
• OPTIONS
• TRACE

반대로 POST, PUT, PATCH, DELETE는 서버의 상태를 변경할 수 있으므로 Safe하지 않다.

---

Idempotent(멱등성)이란?

멱등성(Idempotent)은 같은 요청을 여러 번 보내더라도 서버의 최종 상태가 동일한 특성이다.

여기서 중요한 것은 응답이 아니라 서버의 상태이다.

예를 들어 다음 요청은 사용자를 삭제한다.

DELETE /users/1

응답은 처음엔 200 OK, 다음엔 404 Not Found로 다를 수도 있다.

하지만 서버의 최종 상태는 '사용자 없음'으로 동일하다.

따라서 DELETE는 멱등성을 가진다.

반면 POST는 일반적으로 멱등하지 않다.

POST /users

를 여러 번 호출하면

사용자 1 생성, 사용자 2 생성, 사용자 3 생성

처럼 상태가 계속 변경될 수도 있다.

대표적인 멱등 메서드는 다음과 같다.

• GET
• PUT
• DELETE
• HEAD
• OPTIONS
• TRACE

멱등성은 네트워크 장애 상황에서 특히 중요하다. 클라이언트가 응답을 받지 못해 요청을 재시도하더라도 서버 상태가 예상치 못하게 변경되지 않도록 보장할 수 있기 때문이다.

---

Cacheable(캐시 가능성)이란?

캐시 가능성(Cacheable)은 요청 결과를 저장해두었다가 동일한 요청이 들어왔을 때 재사용할 수 있는 특성이다.

대표적으로 GET 요청은 캐시가 가능하다.

GET /products

첫 번째 요청 시 서버로부터 응답을 받은 후

[
  { "id": 1, "name": "Keyboard" }
]

브라우저나 CDN은 해당 결과를 저장할 수 있다.

이후 동일한 요청이 들어오면 서버에 요청하지 않고 저장된 결과를 반환할 수 있다.

다만 "캐시 가능하다"는 것이 "무조건 캐시된다"는 의미는 아니다.

서버는 Cache-Control, ETag, Last-Modified 같은 헤더를 통해 캐시 정책을 제어할 수 있다.

예를 들어 실시간 주식 시세나 채팅 메시지처럼 최신 데이터가 중요한 경우에는 캐시를 사용하지 않을 수 있다.

Cache-Control: no-store

반면 이미지, CSS, JavaScript 파일처럼 자주 변경되지 않는 리소스는 장기간 캐시할 수 있다.

Cache-Control: max-age=31536000

캐시는 웹 서비스 성능을 향상시키는 핵심 기술 중 하나이며, HTTP가 제공하는 중요한 특성 중 하나이다.

---

HTTP 메서드 종류

• GET
  GET 메서드는 특정 리소스의 표시를 요청합니다. GET을 사용하는 요청은 오직 데이터를 받기만 합니다.

• HEAD
  HEAD 메서드는 GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.

  • Spring MVC에서는 기본적으로 GET이 있으면 body만 제거되는 식으로 HEAD도 같이 처리된다.

• POST
  POST 메서드는 특정 리소스에 엔티티를 제출할 때 쓰입니다. 이는 종종 서버의 상태의 변화나 부작용을 일으킵니다.

• PUT
  PUT 메서드는 목적 리소스 모든 현재 표시를 요청 payload로 바꿉니다.

• DELETE
  DELETE 메서드는 특정 리소스를 삭제합니다.

• CONNECT
  CONNECT 메서드는 목적 리소스로 식별되는 서버로의 터널을 맺습니다.

• OPTIONS
  OPTIONS 메서드는 목적 리소스의 통신을 설정하는 데 쓰입니다.

  • CORS 환경의 preflight 요청이 OPTIONS이다.
  • 실제 요청 전 preflight로 유효한 요청인지 확인하기 위해 사용된다.

• TRACE
  TRACE 메서드는 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 합니다.

  • 서버가 요청을 그대로 되돌려주는(echo같은) 디버깅용 메서드
  • 네트워크 디버깅용으로 존재하지만, wireshark같은 대체 도구가 더 좋다.
  • 브라우저 + XSS 조합으로 Authorization 헤더가 노출될 수 있어서(XST) 대부분 서버에서 disable 설정한다.

• PATCH
  PATCH 메서드는 리소스의 부분만을 수정하는 데 쓰입니다.

---

안전, 멱등, 캐시 가능성은 알겠는데요...
실제로는 GET, POST, DELETE 정도만 사용하던데, 그냥 구현만 제대로 하면 뭘 사용하든 상관 없는거 아닌가요?

HTTP 메서드 의도를 지켜야 하는 이유

HTTP 메서드를 의도에 맞게 사용하는 것은 단순한 규칙이 아니라, HTTP 생태계 전반(브라우저, CDN, 프록시, API Gateway 등)이 메서드 의미를 기반으로 동작하기 때문에 중요하다.

캐싱 최적화

GET은 조회를 의미하고, HTTP 표준상 캐시 가능한 요청으로 분류된다.
따라서 브라우저, CDN, 프록시 서버가 응답을 캐싱할 수 있다.

반면 POST는 기본적으로 캐시 대상이 아니므로 조회 API를 POST로 설계하면 캐싱 이점을 전혀 활용할 수 없다.

결과적으로 불필요한 서버 트래픽 증가로 이어진다.

안전성 (Safety)

GET은 “서버 상태를 변경하지 않는 요청”이라는 의미를 가진다.

안전성이 보장되어야

• 크롤러
• 링크 프리페칭
• 브라우저 prefetch

같은 자동 요청이 발생해도 시스템 상태가 변경되지 않는다.

반대로 조회 API가 DELETE/POST로 잘못 설계되면, 의도치 않은 요청만으로도 데이터가 변경될 수 있다.

멱등성 (Idempotency) 기반 안정성

GET / PUT / DELETE는 동일 요청을 여러 번 수행해도 결과가 동일하도록 설계된다.

이 특성 덕분에:

• 네트워크 timeout 발생 시 retry
• Load Balancer retry
• 클라이언트 재시도 로직

이 안전하게 동작할 수 있다.

반면 POST는 기본적으로 비멱등이므로 재시도 시 중복 생성 문제가 발생할 수 있다.

인프라 및 보안 정책

HTTP 메서드는 단순한 규칙이 아니라, 다양한 인프라 시스템의 정책 기준으로 사용된다.

• API Gateway의 라우팅 및 권한 정책
• WAF(Web Application Firewall)의 요청 필터링
• CORS 정책에서 허용 메서드 제한
• Rate Limiting 정책 분리

따라서 메서드를 잘못 사용하면, 의도하지 않은 차단이나 정책 우회/누락이 발생할 수 있다.

메서드 기준으로 정책이 적용되어 동작하므로 예상하지 못한 결과가 발생할 수 있다.