A megfelelő helyreállítás kiválasztása
Ugyanaz a hibakód két különböző helyzetet ír le. Mielőtt bármit tenne, ellenőrizze a következőt:retryable; a HTTP-állapot önmagában nem árulja el, hogy érdemes-e újrapróbálkozni.
Eltérő bemenet
A kérés feldolgozása még folyamatban van
Ez a példa a következő HTTP-válaszfejlécet is tartalmazza:Retry-After: 1.
Az újrapróbálkozási azonosító állandóságának megőrzése
Az idempotenciát dokumentáló műveleteknél a kulcs hatóköre a szervezetre, a szolgáltatásfiókra, a HTTP-metódusra, az erőforrás elérési útjára és a feloldott API-verzióra terjed ki. Ezek bármelyikének módosítása más újrapróbálkozási azonosítót hoz létre; ez nem állítja helyre az eredeti műveletet. Az azonos szolgáltatásfiók alatti hitelesítő adat cseréje nem változtatja meg ezt az azonosítót, bár a cserélt hitelesítő adatnak továbbra is rendelkeznie kell a megfelelő jogosultsággal. Időtúllépésből történő helyreállításkor tartsa meg az eredeti kulcsot, törzset, elérési utat és verziót. Ne hozzon létre új kulcsot pusztán azért, hogy túljusson az ütközésen: az eredeti írási művelet lehet, hogy már sikeresen lefutott. Ha ismert az erőforrás azonosítója, kérje le az erőforrást, és kövesse a művelet dokumentált helyreállítási eljárását. A befejezett ismételt lejátszás válasza tartalmazza a következőt:Idempotent-Replayed: true, ha a művelet dokumentálja a válasz ismételt lejátszását.
Egy Idempotency-Key küldése nem tesz idempotenssé egy műveletet, kivéve, ha annak referenciadokumentációja kifejezetten támogatja ezt a fejlécet. Az újrapróbálkozás elleni védelmet a művelet megőrzési szabályzata korlátozza; ez nem állandó garancia a duplikációk ellen.
Ha a feldolgozás továbbra sem tisztázódik, forduljon a Living Security ügyfélszolgálatához a következő adatokkal: request_id, UTC időbélyeg, metódus, elérési út és API-verzió. Soha ne küldjön API-kulcsot, ügyfélkulcsot (client secret) vagy hozzáférési tokent.