핵심 요약
GET과 POST의 진짜 차이는 "몸통에 데이터를 싣느냐"가 아니라 안전성(safe)과 멱등성(idempotent)이다. GET은 서버 상태를 바꾸지 않아야 하고(safe), 여러 번 호출해도 결과가 같아야 한다(idempotent). POST는 호출할 때마다 새 리소스를 만들 수 있어 둘 다 아니다. 이 차이 때문에 캐시·재시도·브라우저 뒤로가기 동작이 달라진다.
1. 용어 정리
| 메서드 | Safe | Idempotent | 용도 |
|---|---|---|---|
| GET | O | O | 조회 |
| POST | X | X | 생성·처리 |
| PUT | X | O | 전체 교체 |
| DELETE | X | O | 삭제 |
멱등 = 같은 요청을 100번 보내도 서버 상태 결과가 1번 보낸 것과 같음. DELETE는 한 번 지우면 이후엔 이미 없으니 멱등이다.
2. 그래서 실무에서 뭐가 달라지나
- 캐시 — GET만 안전하게 캐시된다. POST 응답을 캐시하면 사고
- 재시도 — 네트워크 실패 시 GET·PUT은 그냥 재시도해도 되지만, POST 재시도는 중복 생성 위험
- 브라우저 뒤로가기 — POST 후 뒤로가면 "양식을 다시 제출하시겠습니까?" 경고가 뜨는 이유
3. POST를 멱등하게 만들기
POST /payments
Idempotency-Key: 3f9a-... // 클라이언트가 생성
// 서버: 같은 키를 이미 처리했으면
// 새로 만들지 말고 기존 결과를 반환결제처럼 중복이 치명적인 POST는 멱등성 키로 보완한다. 같은 키의 재요청은 새 리소스를 만들지 않고 이전 결과를 돌려준다.
4. 흔한 오해
- "GET은 몸통을 못 싣는다" — 스펙상 가능하지만 많은 서버·프록시가 무시하므로 쿼리스트링을 쓴다
- "민감정보는 POST면 안전" — POST 본문도 HTTPS가 아니면 노출된다. GET이 URL·로그에 남는 문제와는 별개
5. 면접 답변 틀
"GET은 안전하고 멱등해서 캐시·재시도·북마크가 가능하고, POST는 매번 새 결과를 만들 수 있어 그렇지 않습니다. 그래서 조회는 GET, 상태를 바꾸는 건 POST를 쓰고, 결제처럼 중복이 위험한 POST엔 멱등성 키를 붙입니다."
자주 묻는 질문
조회인데 파라미터가 너무 길면 POST를 써도 되나요?
URL 길이 한계나 민감한 검색 조건 때문에 조회에 POST를 쓰는 경우가 있습니다(예: 복잡한 검색). 실용적 타협이지만 캐시·재시도 이점을 잃는다는 걸 알고 쓰세요. 가능하면 GET을 유지하는 게 원칙입니다.
PUT과 POST는 어떻게 구분하나요?
PUT은 "이 위치에 이 상태로 만들어라"라 멱등합니다(같은 PUT 반복=같은 결과). POST는 "이걸 처리해라"로 매번 새 결과를 낼 수 있습니다. 리소스 위치를 클라이언트가 정하면 PUT, 서버가 정하면 POST가 자연스럽습니다.
DELETE가 멱등이라는 게 무슨 뜻인가요?
같은 리소스를 두 번 삭제해도 최종 상태는 "없음"으로 같기 때문입니다. 두 번째 호출이 404를 반환할 수는 있지만 서버 상태를 추가로 바꾸지는 않으므로 멱등으로 봅니다.
댓글 0