[매일메일] HTTP 메서드의 멱등성(BE.250113)

멱등성?

- 연산을 여러 번 적용해도 결과가 달라지지 않는 성질

- 첫 번째 수행을 한 뒤 여러 차례 적용해도 결과를 변경시키지 않는 작업 또는 기능의 속성

 

멱등 함수?

- 절대값 함수: 숫자의 절대값을 계산

- 같은 값에 대해 여러 번 수행해도 처음과 같은 숫자로 돌아옴

 

HTTP 메서드의 멱등성?

- 동일한 요청을 한 번 보내는 것과 여러번 보내는 것이 서로 동일한 효과를 지님

- 돌아오는 값이 같을 뿐 아니라, 서버 상태(DB)에도 영향을 미치지 않음

 

HTTP 메서드 별 멱등성

- GET: 여러 번 호출해도 같은 결과 반환, 리소스에 변화 일으키지 않음

- PUT: 여러 번 호출해도 매번 같은 리소스로 업데이트 되기 때문에 결과가 달라지지 않음

- DELETE: 여러 번 호출해도 삭제된 리소스에 대한 결과는 달라지지 않음

- HEAD, TRACE, OPTIONS도 멱등성을 가짐

 

- 그러나 POST, PATCH는 서버 데이터를 변경해 호출할 때마다 응답이 달라지므로 멱등하지 않음

- POST: 여러 번 호출하면 새로운 리소스가 생성되거나 리소스 상태가 달라질 수 있음

- PATCH: 기존 리소스에 응답을 추가하는 경우(append), 호출 결과가 달라질 수 있음

 

- 안정성(!=멱등성): 리소스를 변경하지 않는 메서드

   - 안정성 -> 멱등성: 안정성이 보장되면 멱등성을 보장함(GET, HEAD, OPTIONS 등)

   - 멱등성 !-> 안정성: 멱등성이 보장되면 항상 안정성이 보장되는 것은 아님(PUT, DELETE 등)

 

활용방안

- 전송 커넥션이 끊어졌을 때 client가 같은 요청을 재시도 해도 되는지 판단 근거

- 사용자가 결제하는 시점에 timeout으로 정상 응답을 받지 못했다. 재시도 해도 되는가?

   - 멱등한 경우: 같은 서버 상태를 보장하기 때문에 문제 없음

       - 중복 요청이라면, 서버에서 실제 요청을 실행하지 않고 이전에 저장된 응답 데이터를 반환

   - 멱등하지 않은 경우: 중복 요청을 보내 문제를 발생시킬 수 있음

      - 결제가 성공했는지 수동으로 확인 후, 실패했다면 고객이 같은 결제를 다시 시도해야 함

 

멱등성 구현: 멱등키를 API 요청에 포함시킴

- 이전 요청과 동일한 멱등키를 가진 요청 = 중복 요청. 첫 번째 요청과 같은 응답을 반환

- 요청 본문, URL 쿼리 매개변수, 헤더 중 하나에 멱등키를 포함해서 보냄

- Idempotency DB에서 멱등키를 조회해서, 유효 기간 내에 동일한 요청이 있다면 저장된 응답 반환

 

- client: 헤더에 멱등키 "Idempotency-Key" 포함해서 요청

- server: 멱등키 DB에 멱등키와 매칭되는 요청 기록을 추가하거나 기존 요청을 조회

 

멱등키 에러 시나리오

- 400: 멱등키 누락 or 형식에 맞지 않는 멱등키

- 409: 이전 요청 처리가 아직 진행 중인데 동일한 멱등키로 새로운 요청이 들어옴

- 422: 동일한 멱등키로 다른 요청 본문을 시도한 경우(이전과 다른 요청을 같은 멱등키로 시도)

 

---

출처

[1] 25.01.13. 매일메일 백엔드 질문 https://www.maeil-mail.kr/

[2] 토스 페이먼츠: 멱등성이 뭔가요 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

[3] HTTP 메소드의 멱등성과 Delete 메소드가 멱등한 이유

https://mangkyu.tistory.com/251