멱등성(Idempotence)이란?
👉 동일한 요청을 여러 번 반복해도 서버의 상태가 변하지 않는 성질
예를 들어 어떤 리소스를 조회하는 GET 요청을 1번 보내든 10번 보내든 결과는 같다.
서버의 데이터가 달라지지 않기 때문이다.
HTTP 메소드의 멱등성이 필요한 이유
-
요청의 재시도
만약 HTTP 요청이 멱등하다면, 요청이 실패한 경우에 주저없이 재시도 할 수 있다.
반면 멱등하지 않은 요청이라면 이미 처리된 요청을 중복해서 보낼 수 있다. -
예시
이미 결제된 요청이 중간에 연결이 끊어져서 다시 결제 요청을 보내는 경우
→ 중복 결제 문제 발생
HTTP 메소드의 멱등 여부
| HTTP 메소드 | 멱등 여부 |
|---|---|
| GET | O |
| POST | X |
| PUT | O |
| PATCH | X |
| DELETE | O |
GET 메소드
- GET은 데이터를 여러 번 조회해도 결과가 같으므로 멱등하다.
예시 (멱등적 설계)
- GET /post/1 요청
- 서버에서 id값이 1인 게시글 조회
- 해당 게시글 데이터 응답
멱등적이지 않은 GET 설계
하지만 만약 개발자가 조회수 기능을 추가하면서 게시글을 조회하면 동시에 조회수도 올리도록 구현하면 어떻게 될까?
- GET /post/1 요청
- 서버에서 id값이 1인 게시글 조회
- 해당 게시글의 조회수 데이터를 1 증가
- 해당 게시글 데이터를 응답
👉 이 경우 GET 요청을 여러 번 보낼 때마다 서버의 상태(조회수)가 변하므로 멱등성이 깨진다. 따라서 조회수 증가 같은 로직은 PATCH 등 별도 요청으로 분리해야 한다.
DELETE 메소드
- DELETE는 특정 리소스를 삭제한다.
- 한 번 삭제된 리소스에 대해 다시 DELETE 요청을 보내도 이미 없는 상태이므로 서버 상태는 변하지 않으므로 멱등하다.
멱등적이지 않은 DELETE 설계
DELETE /posts/last👉 이 경우 요청할 때마다 마지막 게시글이 삭제된다. 즉, 같은 요청이라도 결과가 계속 달라진다. 따라서 이 경우에는 멱등하지 않은 POST /posts/last 같은 방식이 적절하다.
POST 메소드
- POST는 새로운 자원을 생성하는 요청이다.
- 요청할 때마다 새로운 자원이 생기므로 멱등하지 않다.
복구 매커니즘과 멱등성
- 클라이언트가 요청을 보냈는데 응답이 네트워크 문제로 도착하지 않는다면?
- GET/DELETE 같은 요청은 다시 보내는 데 문제가 없다.
- 하지만 POST라면 서버는 요청을 한 번 더 처리할 수 있고, 이 경우 중복 결제 같은 치명적 문제로 이어질 수 있다.
👉 따라서 POST 요청은 단순히 재전송하지 않고, 다른 조치를 취할 수 있도록 설계하는 것이 안전하다.
PUT 메소드
- PUT은 리소스를 전체 교체하거나 없으면 새로 만든다.
- 동일한 요청을 여러 번 보내더라도 서버의 최종 상태는 동일하므로 멱등하다.
상태 코드와 멱등성
PUT요청은 데이터의 상태에 따라 다른 응답 코드를 반환하게 된다.
- 새로 생성한 경우 :
201 created - 기존 데이터를 덮어쓴 경우 :
200 OK또는204 No Content
👉 상태 코드가 달라도 서버 상태는 동일하므로 멱등성은 유지된다.
PATCH 메소드
- PATCH는 리소스의 일부만 수정한다.
- 기본적으로 멱등하지 않다. (하지만 구현 방식에 따라 멱등하게 만들 수도 있음)
PATCH의 멱등 적인 설계 (대체 방식)
PATCH /user/i
{age:20}👉 여러 번 요청해도 age=20으로 동일하게 유지된다.
PATCH의 멱등적이지 않은 설계 (증가 방식)
PATCH /user/1
{ "age": +1 }👉 요청할 때마다 age 값이 계속 증가 → 멱등성 없음
✅ PUT vs PATCH
PUT 메소드는 반드시 멱등성을 보장하지만 PATCH 메소드는 멱등성을 보장하지 않을 수도 있다.
참조
https://mangkyu.tistory.com/251
https://inpa.tistory.com/entry/WEB-🌐-HTTP의-멱등성-·-안정성-·-캐시성-💯-완벽-이해하기
