Scegliere il corretto ripristino
Lo stesso codice di errore descrive due situazioni diverse. Controllareretryable prima di
agire; lo stato HTTP da solo non indica se sia opportuno riprovare.
Input diversi
Richiesta ancora in elaborazione
Questo esempio include anche l’intestazione di risposta HTTPRetry-After: 1.
Mantenere stabile l’identità del nuovo tentativo
Per le operazioni che documentano l’idempotenza, la chiave ha come ambito l’organizzazione, l’account di servizio, il metodo HTTP, il percorso della risorsa e la versione API risolta. La modifica di uno qualsiasi di questi elementi crea un’identità di nuovo tentativo diversa e non consente di ripristinare l’operazione originale. La rotazione di una credenziale con lo stesso account di servizio non modifica tale identità, anche se la credenziale sostitutiva deve comunque disporre delle autorizzazioni necessarie. In caso di timeout, mantenere la chiave, il corpo, il percorso e la versione originali. Non generare una nuova chiave al solo scopo di superare un conflitto: la scrittura originale potrebbe essere già riuscita. Recuperare la risorsa quando ne è noto l’ID e utilizzare la procedura di ripristino documentata per l’operazione. Una ripetizione completata includeIdempotent-Replayed: true laddove l’operazione documenti la riproduzione della risposta.
L’invio di un Idempotency-Key non rende idempotente un’operazione, a meno che la relativa
documentazione di riferimento non supporti esplicitamente tale intestazione. La protezione dai nuovi tentativi è limitata dalla
politica di conservazione dell’operazione e non rappresenta una garanzia permanente contro i duplicati.
Se l’elaborazione rimane irrisolta, contattare il supporto di Living Security
indicando request_id, timestamp UTC, metodo, percorso e versione API. Non includere mai
una chiave API, un client secret o un token di accesso.