HTTP safe와 idempotent는 같은 뜻인가

safe는 요청의 정의된 의미가 읽기 전용인지 묻고, idempotent는 같은 요청을 여러 번 적용한 의도된 서버 효과가 한 번 적용한 효과와 같은지 묻습니다. 두 속성은 같지 않습니다.

GET은 safe이면서 idempotent이고, PUT은 리소스를 바꾸므로 safe는 아니지만 idempotent입니다. POST는 일반적으로 둘 다 아닙니다. safe라고 해서 서버의 모든 부수 효과나 로그가 전혀 없다는 뜻은 아닙니다.

읽기 전용 의도와 반복 효과를 따로 묻습니다

HTTP 메서드의 safe 여부는 클라이언트가 대상 리소스에 어떤 의미 효과를 요청하는지 봅니다. safe method는 정의된 의미가 본질적으로 읽기 전용이어야 합니다. 반면 idempotent 여부는 동일 요청을 여러 번 보내도 서버에 의도된 효과가 한 번 보낸 경우와 같은지 따집니다. 이 기준은 응답이 완전히 같은지, 로그 행 수가 같은지 묻지 않습니다. 각 성질은 서로 다른 질문이므로 한쪽이 참이라고 다른 쪽도 자동으로 참이라고 결론 내릴 수 없습니다.

세 요청을 속성별로 분류합니다

GET은 정보를 조회하므로 safe입니다. RFC 9110은 safe method도 idempotent method에 포함한다고 설명합니다. PUT은 지정한 리소스의 상태를 요청 본문에 맞추므로 서버 상태 변경을 요청합니다. 따라서 safe는 아니지만 같은 PUT을 다시 보내도 의도된 리소스 상태가 한 번 보낸 것과 같아 idempotent입니다. POST /payments는 이 교육용 가정에서 새 결제 처리를 요청하므로 같은 POST를 반복하면 의도된 효과가 추가될 수 있어 두 속성이 없습니다.

GET /profile           -> 읽기 요청, safe + idempotent
PUT /profile {name:A}  -> 상태 변경 요청, not safe + idempotent
POST /payments         -> 추가 처리 요청, not safe + not idempotent

동일한 질문 두 개로 판정합니다

1. 요청자가 리소스 변경을 요구하는 메서드 의미인지 확인합니다.
2. 요청의 정의된 의미가 읽기 전용이면 safe로 표시합니다.
3. 완전히 같은 요청을 반복했을 때 의도된 서버 효과가 한 번 보낸 경우와 같은지 봅니다.
4. safe와 idempotent를 각각 판단한 뒤 표에 표시합니다.
5. 로그나 응답 코드가 달라졌다는 사실만으로 idempotent를 부정하지 않습니다.

서버의 부수 효과와 의도된 효과를 구별합니다

safe method를 처리하는 서버도 접근 로그를 기록하거나 계량 정보를 갱신할 수 있습니다. RFC 9110의 정의는 이런 구현상의 모든 부수 효과를 금지하지 않습니다. 중요한 기준은 클라이언트가 해당 추가 동작을 요청하거나 기대하지 않는다는 점입니다. 그러므로 safe를 ‘서버 데이터가 어떤 형태로도 바뀌지 않는다’로 외우면 과도한 해석이 됩니다.

idempotent도 응답 본문이나 상태 코드가 매번 같아야 한다는 뜻이 아닙니다. 첫 PUT에는 리소스를 새로 만들었다는 응답이 오고, 다음 요청에는 이미 같은 상태라는 응답이 올 수 있어도 의도된 효과가 동일하면 idempotent일 수 있습니다. 반면 서버 로그에 요청마다 기록이 한 줄씩 추가될 수 있습니다. 이 기록만 보고 메서드 속성을 뒤집지 마세요. 연결이 끊겨 응답을 못 받은 뒤 재시도할 때 idempotent한 메서드는 반복 전송의 성질을 판단하는 데 특히 중요합니다.