Restful: 멱등성 키(Idempotency-Key)

멱등성(Idempotency)은 기본적으로 수학에서 사용되는 개념인데, 웹 시스템에서도 쓴다. 같은 연산을 여러번 하더라도 상태가 달라지지 않는다는 것을 뜻한다.

이를테면 Restful API에서 GET 메서드의 API는 여러번을 실행하더라도 그 응답값이나 상태값이 달라지지 않으니 당연히 멱등하다고 할 수 있다.

그리고 그건 일부 가변적 Method들의 경우도 마찬가지다.
PUT 메서드의 API도 그렇다. 이름을 "John"으로 수정하는 PUT API를 호출한다면, 한번 호출하나 두번 호출하나 같은 동작을 보장해야 한다. 그러므로 멱등하다고 할 수 있다.

이건 웹 표준에도 어느정도 정의가 되어있는 부분이다.

참조 https://www.rfc-editor.org/rfc/rfc7231#section-8.1.3,
출처 https://docs.tosspayments.com/guides/using-api/idempotency-key
DELETE도 마찬가지로 한번 삭제하나 두번 삭제하나 같아야 하니 멱등해야 한다.
반대로 POST는 신규 리소스를 생성하는 것이니 한번 호출했을 때는 하나가 생길 것이고, 두번 호출하면 하나가 더 생겨서 2개가 생길 것이다. 따라서 멱등하지 않다.

문제가 되는 경우

사실 같은 API를 두번 이상 쏘는 경우는 그렇게 자주 발생하지는 않는다. 클라이언트 코드를 이상하게 만든게 아니라면 말이다.

하지만 어쩔수 없는 장애상황이란 것도 있기 마련이다. 네트워크가 불안정할 경우에는 API를 쏴서 API가 성공했는데 성공 응답을 받지 못할 수가 있다. 그러면 클라이언트는 그걸 모르고 다시 API를 쏠 수가 있다.

일반적인 API들이라면 큰 문제가 발생하지는 않겠지만, 뭔가 돈이 오가는 중요한 기능이라면 문제가 심각해질 수도 있다. 돈이 2번 송금된다거나... 하는 끔찍한 사태 말이다.

해결책: 멱등성 키

이런 위의 문제상황을 해결하기 위해 나온 개념이 바로 멱등성 키다.
이것도 웹 표준에서 제안된 부분이다.

1. 클라이언트는 API를 호출할때 "Idempotency-Key"라는 이름의 헤더값에 uuid 같은걸로 랜덤 키값을 생성해서 보낸다.
2. 무언가 장애상황으로 인해서 API가 실패했을 경우, 동일한 "Idempotency-Key" 값으로 API를 다시 쏜다.
3. 서버는 동일한 "Idempotency-Key"으로 들어온 요청에 대해서, 첫번째로 들어온 API 요청만 제대로 처리하고, 이후에 들어온건 status 409를 던지거나 이전에 들어왔던 리스폰스만 그대로 돌려준다.

서버에서 이걸 하려면 Idempotency-Key와 응답값 쌍을 DB로 저장하기만 하면 된다. 그냥 캐싱이다.
보통은 DynamoDB 같은 저렴하고 간편한 Key-Value 데이터베이스를 사용하는 편이 간단할 것이다.

상태코드는 이렇게 쓰면 된다고 한다.

출처: https://docs.tosspayments.com/guides/using-api/idempotency-key

참조
https://greenbytes.de/tech/webdav/draft-ietf-httpapi-idempotency-key-header-latest.html
https://docs.tosspayments.com/guides/using-api/idempotency-key
https://velog.io/@tosspayments/%EB%A9%B1%EB%93%B1%EC%84%B1%EC%9D%B4-%EB%AD%94%EA%B0%80%EC%9A%94
https://www.rfc-editor.org/rfc/rfc7231#section-8.1.3
https://www.berkansasmaz.com/every-programmer-should-know-idempotency/