9.2.2 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.
요청 메서드가 '멱등성'을 갖는다고 간주되는 경우는, 해당 메서드를 사용한 여러 번의 동일한 요청이 실제 서버에 미치는 변화가 단일 요청의 효과와 같을 때다. 이 명세에서 정의된 요청 메서드들 중 PUT, DELETE, 그리고 안전한 요청 메서드들은 멱등성을 갖는다.
추가적인 나의 생각:
PUT 메서드가 좀 애매하다. 이럴 땐 직관적으로 와닿을 수 있는 case로 분석해본다. POST같은 경우, 결제를 생각해보면 똑같은 요청을 한번 보낼 때와 여러 번 보낼때가 다르다. 결제 금액이 10000원이라고 가정하면 1번 요청했을 때는 10000원만 지불되고 5번 요청했을 때는 50000원이 지불되기 때문이다.
PUT 요청인 경우, 회원 정보 수정을 예로 들 수 있다. 홍길동이란 사람이 휴대전화번호가 바뀌어서 회원정보 수정을 한다고 했을 때, 한번 요청되나 여러번 요청이 되나 똑같이 바뀐 휴대전화번호로 덮어씌어진다. 즉, 여러 번의 동일한 요청이 단일 요청의 효과와 같다고 볼 수 있다. 따라서, PUT의 경우 멱등성을 갖는다.
A client SHOULD NOT automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are actually idempotent, regardless of the method, or some means to detect that the original request was never applied.
클라이언트는 멱등성이 없는 메서드를 사용한 요청을 자동으로 재시도해서는 안 됩니다. 단, 다음의 경우는 예외:
- 해당 요청의 의미가 실제로 멱등성을 가진다는 것을 확실히 알고 있는 경우
- 원래의 요청이 서버에 전혀 적용되지 않았다는 것을 확인할 수 있는 방법이 있는 경우
따라서, 서버측에서는 POST에 관련된 로직은 id에 유니크키설정을 하여 중복을 방지한다. 또한 프론트측에서도 중복 제출 방지, 네트워크 오류에 대한 대비를 고려해야한다. 이렇게 POST에서의 여러번 요청은 항상 신경을 써야한다.
reference:
RFC 9110 - HTTP Semantics
