HTTP method 공부 (GET,POST,HEAD,TRACE,OPTIONS)

1️⃣ 한 줄 정의 (가장 중요)

REST API는 HTTP를 기반으로, 자원(Resource)을 URI로 식별하고
표준 HTTP 메서드를 통해 자원의 상태(State)를 표현(Representation)하고 전송하는 아키텍처 스타일입니다.

1) Safe / Idempotent가 뭔가?

Safe (안전)

• 서버의 상태를 “변경하지 않는” 요청
• 즉 “조회용” 성격
• 예: GET, HEAD, OPTIONS (일반적으로)

주의: “안전”은 보안(safe security)이 아니라 부작용(side effect) 없음 의미.

Idempotent (멱등)

• 같은 요청을 여러 번 해도 결과가 같아야 함
• “서버 최종 상태” 기준으로 같으면 멱등

예)

• DELETE /users/1을 10번 → 최종적으로 “1번 유저는 없음” (같음) → 멱등
• POST /orders를 10번 → 주문 10개 생성 (달라짐) → 비멱등

멱등(Idempotent)의 기준

같은 요청을 여러 번 했을 때:

• 리소스의 최종 상태가 동일하면 멱등
• 매번 호출할 때마다 상태가 계속 바뀌거나(누적 생성/증가) 부작용이 누적되면 비멱등

 

2) 각 Method 상세

GET — 조회 (Safe ✅ / Idempotent ✅)

의미

• 자원의 표현(Representation)을 가져온다
• 서버 상태를 바꾸지 않는 게 원칙

특징

• Safe: DB 조회만 하고 끝
• Idempotent: 100번 호출해도 결과가 “동일 조건이면” 동일
• 캐시 가능(Cacheable): 프록시/브라우저 캐시의 핵심 대상
• QueryString 사용 가능: /users?age=20

주의(실무 함정)

• GET에서 “조회하면서 조회수 증가” 같은 상태 변경을 넣으면 REST 관점에서 안티패턴
  • 조회수 증가가 필요하면 이벤트 처리(비동기)나 별도 엔드포인트 고려

---

POST — 생성/처리 (Safe ❌ / Idempotent ❌)

의미

• “서버에게 처리를 위임한다”
• 보통 “생성(Create)”에 많이 쓰이지만, 사실상 가장 범용

특징

• Non-idempotent가 일반적
  • 같은 POST를 2번 보내면 2개 생성될 수 있음
• 서버가 새 자원 생성 시 보통:
  • 201 Created
  • Location: /resource/{id} 헤더로 새 자원 위치 알려줌

실무에서 POST가 필요한 케이스

• 생성
• 결제 요청, 작업 실행처럼 “명령(Command)” 성격
• 복잡한 검색(조건이 길고 body로 보내야 할 때) → POST /search

멱등하게 만들 수도 있음(고급)

• Idempotency-Key(결제 API들이 자주 사용)
• 같은 키로 재시도해도 한 번만 처리

---

PUT — 전체 수정/생성(대체) (Safe ❌ / Idempotent ✅)

의미

• URI로 지정된 자원을 **“전체 교체(replace)”**한다
• 자원이 없으면 생성으로 정의하기도 함(서버 정책)

예)

• PUT /users/123 with full JSON
  → 123 유저의 상태를 “이 JSON으로 통째로 맞춘다”

왜 Idempotent?

• 같은 PUT 요청을 여러 번 보내도 최종 상태는 동일
  • “교체”이기 때문

실무 팁

• PUT에는 “전체 자원 표현”이 들어오는 게 이상적
• 일부 필드만 보내고 나머지 유지하면 PUT의 의미가 PATCH와 섞여서 애매해짐

---

PATCH — 부분 수정 (Safe ❌ / Idempotent ❓(보통 ❌))

의미

• 자원의 “일부만 변경”한다

왜 Non-idempotent로 분류되는 경우가 많나?

PATCH는 방식이 2가지가 있어서 헷갈림:

1. partial object merge 스타일

 

{ "name": "kim" }

• 이런 경우는 사실상 동일 요청 반복해도 결과가 같아서 멱등처럼 보일 수 있음

1. operation(연산) 기반 스타일 (RFC 6902 JSON Patch)

 

[ {"op":"replace","path":"/name","value":"kim"}, {"op":"increment","path":"/viewCount","value":1} ]

• increment 같은 연산은 반복 시 결과가 달라짐 → 비멱등

✅ 결론:

• PATCH는 구현 방식에 따라 멱등/비멱등이 달라질 수 있음
• 면접에서는:
  “대부분 비멱등으로 취급하지만, replace/merge만 하면 멱등이 될 수도 있다” 라고 말하면 점수 높음

---

DELETE — 삭제 (Safe ❌ / Idempotent ✅)

의미

• 지정된 자원을 삭제한다

왜 Idempotent?

• 첫 번째 DELETE로 삭제 성공
• 두 번째 DELETE는 “이미 없음” 상태지만,
  • 최종 상태는 계속 “없음” → 동일
• 그래서 멱등

응답 코드 실무 예

• 204 No Content (삭제 성공)
• 이미 없을 때도 204로 “멱등하게” 처리하는 경우 많음
  또는 404 Not Found를 주는 경우도 있음(정책)

---

3) HEAD / TRACE / OPTIONS도 자세히

HEAD — GET의 “헤더만” 버전 (Safe ✅ / Idempotent ✅)

의미

• GET과 동일한 요청이지만 Body는 반환하지 않고 Header만 받음

언제 쓰나?

• 리소스 존재 확인, 메타데이터 확인
  • Content-Length (크기)
  • Last-Modified (수정 시각)
  • ETag (캐시 검증)
• “다운로드 전에 크기 확인” 같은 용도

실무 주의

• 서버가 GET/HEAD 처리 로직을 잘못 분리하면
  HEAD에서 Content-Length 등 메타가 틀어질 수 있음

---

OPTIONS — “이 리소스가 뭘 지원하냐?” (Safe ✅ / Idempotent ✅)

의미

• 서버/리소스가 지원하는 통신 옵션을 조회

대표 사례: CORS Preflight

브라우저가 실제 요청 전에 이런 식으로 물어봄:

 

OPTIONS /api/orders Access-Control-Request-Method: POST Origin: https://front.example

서버가 응답:

 

Access-Control-Allow-Methods: GET,POST,OPTIONS Access-Control-Allow-Origin: https://front.example

실무에서 중요 포인트

• CORS 문제가 나면 OPTIONS가 막혀있는지 확인해야 함
• API Gateway/WAF에서 OPTIONS 차단하면 프론트 호출이 실패

---

TRACE — “요청이 중간에서 어떻게 변했나?” (Safe ✅ / Idempotent ✅)

의미

• 요청이 프록시/게이트웨이 등을 지나면서
  어떻게 변경되었는지를 서버가 그대로 되돌려줌(루프백)

왜 거의 안 쓰나? (보안)

• TRACE는 과거에 XST(Cross-Site Tracing) 같은 공격에 악용 가능성이 있어서
• 대부분 운영 환경에서는 비활성화가 일반적

---

(보너스) CONNECT — 프록시 터널링(HTTPS)용

요청하진 않았지만 TRACE랑 같이 자주 언급됨.

• HTTPS 프록시 터널을 만들 때 사용
• 일반 API 서버에서는 거의 안 씀

---

4) 면접에서 이 파트 답변 “한 방” 정리

“GET/HEAD/OPTIONS는 safe이고, GET/HEAD는 캐싱과 메타데이터 검증에 자주 쓰입니다.
POST는 일반적으로 비멱등이라 재시도 시 중복 처리를 막기 위해 Idempotency-Key 같은 설계를 합니다.
PUT/DELETE는 자원의 최종 상태를 동일하게 만드는 멱등 메서드이고,
PATCH는 구현 방식(merge vs 연산)에 따라 멱등성이 달라질 수 있습니다.
TRACE는 디버깅 목적이지만 보안 이슈로 운영에서는 보통 막습니다.”