[Web] HTTP 메소드의 멱등성과 안정성이란? PUT 멱등성, PATCH 멱등성

멱등의 사전적 의미

 

[그림 1] 멱등의 사전적 의미 (출처 : 네이버 국어사전)

 

네이버 국어사전에 의하면 멱등은 '연산을 여러 번 적용하더라도 결괏값이 달라지지 않는 일'을 뜻한다.

 

 

HTTP 메소드의 멱등성(Idempotent)

GET, POST, PUT, DELETE 등의 HTTP 메소드 중에는 멱등성을 갖는 메소드들이 존재한다.

 

HTTP 메소드가 멱등성을 갖는다는 것은 동일한 HTTP 요청을 몇 번을 보내든 같은 결과를 만든다는 것이다.

하지만 이렇게 HTTP 메소드의 멱등성을 이해하면 헷갈릴 수 있다. 중요한 것은 반환받는 결과가 같다는 뜻이 아니라 서버의 결과(상태)가 같다는 것이다.

 

즉, HTTP 메소드의 멱등성은 HTTP 요청을 몇 번을 보내더라도 일정한 서버의 상태를 만듦을 의미한다고 생각하자.

 

HTTP 메소드들의 멱등성 여부는 아래와 같다.

HTTP 메소드	멱등성 여부
GET	O
PUT	O
DELETE	O
HEAD	O
TRACE	O
POST	X
PATCH	△

 

주요 메소드들에 대해 알아보자.

 

GET 메소드

GET 메소드는 몇 번의 요청을 보내도 항상 같은 값을 반환한다. 따라서 멱등성을 가진다.

 

만약 GET 메소드 요청을 계속해서 보내는 도중 PUT 메소드 등으로 값이 바뀌더라도 멱등성이 보장되는 것일까?

 

그렇다. 외부의 영향으로 값이 바뀐 것은 멱등성의 고려 사항이 아니다. 

 

외부 영향 없이 GET 메소드를 연속으로 계속 요청했다면 같은 값을 반환했을 것이다.

 

 

PUT 메소드

PUT 메소드 요청을 처음 보내면 데이터가 없다면 생성하고 있다면 수정할 것이다. 그 이후 다시 PUT 메소드를 계속해서 보낸다면 똑같은 내용을 덮어씌우는 것을 반복할 것이다.

 

서버의 상태를 기준으로 보면 PUT 메소드가 처음 오든, 두 번째 이상 오든 상태가 똑같다.

 

A라는 데이터를 생성했든, A라는 데이터에 A를 덮어씌우든 데이터는 A인 상태로 똑같기 때문이다. 

 

따라서 PUT 메소드도 멱등성을 가진다.

 

 

DELETE 메소드

DELETE 메소드가 가장 헷갈린다. DELETE 메소드를 처음으로 요청하면 서버의 데이터가 삭제된다. 이후 DELETE 메소드를 보내면 404 NOT FOUND 에러를 반환할 것이다. 

 

하지만 이 역시 서버를 기준으로 보면 상태가 변하지 않은 것이다.

 

A라는 데이터가 있는데 DELETE 메소드를 처음 보내면 A라는 데이터가 없는 상태가 될 것이다.

이후 DELETE 메소드를 계속 보내도 서버에는 A라는 데이터가 없는 상태가 일정하게 유지된다.

 

따라서 DELETE 메소드도 멱등성을 가진다.

 

자원 식별자를 명시하지 않는 DELETE 메소드

DELETE /item/last

위와 같이 특정한 자원 식별자를 명시하지 않고 무조건 마지막 데이터를 삭제하는 DELETE API를 설계했다고 하자.

 

이는 멱등성을 보장하지 않는다. A,B,C,D라는 데이터가 서버에 있을 때 처음 요청 이후에는 A,B,C 가 데이터가 남고

두 번째 요청 이후에는 A,B 데이터가 남을 것이다. 

 

즉, 서버의 상태가 일정하지 않기 때문에 멱등성을 갖지 않는 것이다.

 

이처럼 자원 식별자를 명시하지 않는 삭제 요청을 구현하기 위해서는 멱등성을 가지지 않는 POST 메소드로 설계하는 것이 더 적절하다.

 

 

POST 메소드

POST 메소드는 매 요청마다 서버에 데이터를 추가하게 된다. 즉 같은 요청이라도 서버의 상태가 변하게 된다.

 

A라는 데이터를 추가하는 POST 메소드를 처음 보내면 서버는 A라는 데이터를 갖게 될 것이다.

두 번째 요청을 보내면 서버는 A,A 두 개의 데이터를 갖게 될 것이다.

 

즉, 서버의 상태가 일정하지 않는다.

 

따라서 POST 메소드는 멱등성을 가지지 않는다.

 

PATCH 메소드

PATCH 메소드는 멱등성을 가지도록 설계할 수도 있고 가지지 않도록 설계할 수도 있다.

 

PATCH는 데이터를 수정할 수 있다. 이때 일정한 값으로 수정하도록 설계한다면 멱등성을 가질 수 있다.

 

하지만 만약 매 요청마다 값이 변하도록 설계한다면 멱등성을 가지지 않는다.

 

예를 들어 10이라는 데이터가 있을 때 이를 12로 변경하는 PATCH 메소드는 멱등성을 갖는다.

 

하지만 10이라는 데이터가 있을 때 여기에 1을 더하는 PATCH 메소드는 멱등성을 가지지 않는다.

 

따라서 PATCH 메소드는 멱등성을 가질 수도, 가지지 않을 수도 있다.

 

 

HTTP 메소드의 안정성(Safety)

HTTP 메소드의 안정성은 HTTP 요청을 몇 번을 보내든 서버의 상태가 변하지 않고 일정함을 의미한다.

 

HTTP 메소드의  안정성은 멱등성과 헷갈릴 수 있다. 

 

HTTP 메소드의 멱등성은 서버의 상태를 바꾸지 않는다는게 아니다. 예를 들어 PUT 메소드를 처음 보내면 데이터가 생겨나기도하고 DELETE 메소드를 요청하면 서버에서 데이터가 삭제 되기도 한다. 즉, 서버의 상태가 바뀌기도 한다.

다시 말하자면 멱등성은 몇 번의 요청에도 서버의 같은 결과를 만든다는 뜻이다.

 

반면 HTTP 메소드의 안정성은 아예 서버의 상태를 바꾸지 않음을 뜻한다. 

 

따라서 오직 데이터를 조회(READ)하는 GET, HEAD 등의 메소드만 안정성을 가진다. 

 

 

HTTP 메소드의 안정성은 다음과 같다.

HTTP 메소드	안정성 여부
GET	O
PUT	X
DELETE	X
HEAD	O
TRACE	X
POST	X
PATCH	X

 

그렇기에 모든 안정성을 가진 메소드는 멱등성을 가진다. 반면 반대는 성립하지 않는다.

 

 

---

참고

 

1. https://www.mscharhag.com/api-design/http-idempotent-safe

2. https://restfulapi.net/idempotent-rest-apis/