Kies het juiste herstel
Dezelfde foutcode beschrijft twee verschillende situaties. Controleerretryable voordat
u actie onderneemt; de HTTP-status alleen geeft niet aan of u het opnieuw moet proberen.
Andere invoer
Aanvraag wordt nog verwerkt
Dit voorbeeld bevat ook de HTTP-responseheaderRetry-After: 1.
Houd de retry-identiteit stabiel
Voor bewerkingen waarvoor idempotentie is gedocumenteerd, is de sleutel gekoppeld aan de organisatie, het serviceaccount, de HTTP-methode, het resourcepad en de opgeloste API-versie. Als u een van deze onderdelen wijzigt, ontstaat er een andere retry-identiteit; de oorspronkelijke bewerking wordt dan niet hersteld. Het roteren van een credential onder hetzelfde serviceaccount wijzigt die identiteit niet, hoewel de vervangende credential nog wel over de juiste rechten moet beschikken. Behoud de oorspronkelijke sleutel, body, het pad en de versie wanneer u herstelt na een time-out. Genereer niet zomaar een nieuwe sleutel om een conflict te omzeilen: de oorspronkelijke schrijfactie kan al zijn geslaagd. Haal de resource op als de ID bekend is en volg de gedocumenteerde herstelprocedure van de bewerking. Een voltooide replay bevatIdempotent-Replayed: true wanneer de bewerking responsreplay documenteert.
Het verzenden van een Idempotency-Key maakt een bewerking niet idempotent, tenzij de
referentie van die bewerking deze header expliciet ondersteunt. De bescherming tegen herhaalde aanvragen is beperkt door het
bewaarbeleid van de bewerking; het is geen permanente garantie tegen duplicaten.
Als de verwerking onopgelost blijft, neemt u contact op met Living Security Support
en vermeldt u de request_id, de UTC-tijdstempel, de methode, het pad en de API-versie. Voeg nooit
een API-sleutel, client secret of toegangstoken toe.