멱등 원 (idempotent) REST 기반 POST API 호출을 빌드하고 있습니다. 네트워크 오류 동안 클라이언트가 중복 리소스를 만드는 것을 방지하기 위해 멱등 원 행동을 구현하려고합니다. & 시간 초과입니다. 클라이언트는 모든 API 호출의 요청 헤더에 ClientToken을 전달합니다. 내 POST 요청에 표준 페이로드가 있고 주위에 유효성 검사 논리가 있습니다. 재 시도 중에 API에서 예상되는 이상적인 멱등 원 행동은 무엇입니까? 그것은 단지 ClientToken에 의존하고 요청 페이로드를 무시해야합니까? 아니면 ClientToken을 사용하여 멱등 원 수표를 호출하기 전에 요청 페이로드에서 유효성 검사 로직을 실행해야합니까?idempotent POST API 호출은 idempotency를 확인하기 위해 클라이언트 토큰을 사용하기 전에 페이로드 요청 페이로드를 확인해야합니까?
우선, HTTP 메소드 인 POST는 멱등구가 아닙니다. 멱등 원은 여러 개의 동일한 요청이 단일 요청과 동일한 효과를 가져야 함을 의미합니다.
페이로드를 변경하면 더 이상 동일한 요청이 발생하지 않습니다. 동일한 토큰으로 사용하면 서버에서 어떤 일이 발생합니까? 두 번째, 다른 요청이 부작용을 유발합니까? 만약 그렇다면 그것은 더 이상 발휘되지 않습니다. 반면에 결과가 동일하다면 메소드는 유효하지 않으므로 페이로드는 중요하지 않지만 더 이상 HTTP의 멱등 원성을 유지하는 데 필요한 동일한 요청을 가지지 않습니다.
개인적으로 동일한 페이로드를 갖고 다른 페이로드가있는 후속 요청을 거부하는 요청을 확인합니다.
의존적이지만 구현 한 멱등 원류 API의 경우 항상 토큰을 먼저 확인합니다.
데이터베이스에 변경된 내용 (예 : 새 리소스 삽입)과 동일한 트랜잭션에 idempotency 토큰 만 저장 했으므로 요청한 항목이 이미 커밋되고 이전에 작동했음을 알고 있습니다.
토큰이있는 경우 페이로드의 유효성을 검사하기 직전에 링크 (POST의 경우)가 생성 된 클라이언트에 201을 반환합니다.
이 이유는 클라이언트 용 게임 규칙이 idempotency 토큰이기 때문에 똑같은 요청을 정확히 재 시도 할 수 있기 때문입니다. 누군가가 페이로드를 바꿀만큼 어리석은 클라이언트를 작성하고 동일한 멱등 원 (dentem)을 사용하는 경우, 그것은 그 머리에 있습니다.
멱등 원 (idempotency) 토큰을 검사하는 보너스는 페이로드의 유효성 검사가 무거울 경우 잠재적으로 약간의 유효성 검사 작업을 저장할 수 있다는 것입니다.
알 수 있습니다. 클라이언트가 요청을 엉망으로 만들었지 만 동일한 ClientToken이지만 페이로드가 다른 경우 다른 오류를 반환해야합니까? 서버는 동일한 ClientToken을보고 새로운 요청으로 처리 할 수 없으며 요청 페이로드가 동일하지 않기 때문에 이전의 성공적인 응답을 반환 할 수 없습니다. – user3236022
@ user3236022 : 예, 동일한 클라이언트 토큰이지만 페이로드가 다른 추가 요청에 대해서는 4xx 범위의 상태 코드를 반환 할 수 있습니다. – Bogdan
HTTP 표준은 프록시가 프록시와 같은 모든 중간체와 관련하여 POST가 안전하지 않은 것으로 취급한다고 말합니다 ... 토큰을 사용하여 멱등하지 않은 POST를 구현하는 것은 전적으로 가능합니다. 그러나 클라이언트는 규칙에 따라 재생해야하며 동일한 페이로드로 실패한 요청 만 다시 시도해야합니다. 그렇지 않으면 결과가 머리에 있습니다. – nrjohnstone