[TIL] HTTP 멱등성

HTTP 멱등성

---

HTTP 멱등성이란?

Idempotent Methods

   A request method is considered "idempotent" if the intended effect on
   the server of multiple identical requests with that method is the
   same as the effect for a single such request.  Of the request methods
   defined by this specification, PUT, DELETE, and safe request methods
   are idempotent.

   Like the definition of safe, the idempotent property only applies to
   what has been requested by the user; a server is free to log each
   request separately, retain a revision control history, or implement
   other non-idempotent side effects for each idempotent request.

   Idempotent methods are distinguished because the request can be
   repeated automatically if a communication failure occurs before the
   client is able to read the server's response.  For example, if a
   client sends a PUT request and the underlying connection is closed
   before any response is received, then the client can establish a new
   connection and retry the idempotent request.  It knows that repeating
   the request will have the same intended effect, even if the original
   request succeeded, though the response might differ.

📌 [사전] 멱등 : 연산을 여러 번 적용하더라도 결괏값이 달라지지 않는 일.
동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말함.

GET, HEAD, PUT, DELETE, 모든 안전한 메서드(OPTIONS, TRACE (en-US))는 멱등성을 가지며, POST, PATCH, CONNECT메서드는 그렇지 않음. 멱등하지 않은 메서드에 멱등성을 제공하려면, 서버에서 멱등성을 구현해야함.
*안전한 메서드 : 서버 측의 상태 정보를 변경하지 않는 메서드

 

HTTP 메서드의 안전성과 멱등성은 어떻게 다를까?

- 안전성이 보장된 메서드는 멱등성도 보장하지만, 멱등성을 지닌 메서드가 항상 안전성을 보장하지는 않음.
- 안전성 : 리소스를 변경하지 않음

- 멱등성 : 여러번 연산하더라도 동일한 상태를 가짐

HTTP 멱등성

• 멱등성은 '요청의 효과'를 보고 판단
• 즉, 멱등성을 따질 땐 실제 서버의 백엔드 상태만 보면 되며, 각 요청에서 반환하는 응답 코드는 다를 수 있음
  • 첫 번째 [DELETE](<https://developer.mozilla.org/ko/docs/Web/HTTP/Methods/DELETE>) 요청이 [200](<https://developer.mozilla.org/ko/docs/Web/HTTP/Status/200>)을 반환한다면, 그 이후는 아마 [404](<https://developer.mozilla.org/ko/docs/Web/HTTP/Status/404>)를 반환
  • 즉, DELETE가 멱등성을 가진다는 것은, REST API에서 개발자는 DELETE 메서드를 사용해 "목록의 마지막 항목 제거" 기능을 구현해서는 안된다는 것
• 서버는 멱등성을 보장하지 않음
• 일부 애플리케이션은 잘못된 구현으로 멱등성 제약을 어길 수 있음
• GET /pageX HTTP/1.1는 멱등성을 가짐
  • 여러 번 연속해서 호출해도 클라이언트가 받는 응답은 동일

  GET /pageX HTTP/1.1
      GET /pageX HTTP/1.1
      GET /pageX HTTP/1.1
      GET /pageX HTTP/1.1
  

• POST /add_row HTTP/1.1는 멱등성을 갖지 않음
  • 여러 번 호출할 경우, 여러 열을 추가

  POST /add_row HTTP/1.1
      POST /add_row HTTP/1.1   -> Adds a 2nd row
      POST /add_row HTTP/1.1   -> Adds a 3rd row
  

• DELETE /idX/delete HTTP/1.1 멱등성을 가짐
  • 상태 코드는 응답마다 달라질 수 있음

  DELETE /idX/delete HTTP/1.1   -> Returns 200 if idX exists
      DELETE /idX/delete HTTP/1.1   -> Returns 404 as it just got deleted
      DELETE /idX/delete HTTP/1.1   -> Returns 404
  

API 관점에서 바라본 멱등성

- 멱등성을 지키면 -> 시스템에 의도하지 않은 문제를 일으키지 않고 요청을 재시도 할 수 있게 됨.

    - 결제 api에서 네트워크 오류나 타임아웃으로 인해 결과를 받지 못하였다고 예를 들어보자.

       - 멱등성이 보장되지 않은 API라면

             결제가 성공했는지 실패했는지 수동으로 확인해야함.

             고객이 같은 결제를 다시 시도해야 함

       - 멱등성이 보장된 API 라면

              실수로 중복 요청을 하더라도, 실제로는 결제가 되지 않아 안심하고 여러번 요청 할 수 있음

              다시 같은 요청을 보내지 않고, 전에 받지 못한 결과만 다시 받을 수 있음.

멱등한 요청인지 알 수 있는 방법

- 요청 헤더에 멱등키를 포함해서 보냄

1. API서버는 요청마가 헤더에 멱등키가 있는지 확인
2. 멱등키를 저장하기 위한 DB를 만들어두고, 멱등키가 포함된 요청이 들어왔을 때 DB를 탐색
   • 일정 기간이 지나면 멱등키를 지움
3. 기존에 해당 키로 들어온 요청이 있다면, 서버는 실제로 요청을 실행하지 않고, 저장되어있던 응답 데이터를 클라이언트로 전송
   • 없다면 요청을 실행

- 도메인 서버 로직의 복잡도가 높다면, 멱등성 로직을 추가했을 때 API 성능 개선에도 도움이 됨.

   (멱등 키를 가진 요청은 도메인 서버로 바로 처리되지 않기 때문.)

 

참고자료

https://developer.mozilla.org/ko/docs/Glossary/Idempotent

https://datatracker.ietf.org/doc/html/draft-idempotency-header-01#section-2.7

https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/

The Idempotency HTTP Header Field

멱등성 - MDN Web Docs 용어 사전: 웹 용어 정의 | MDN