Skip to main content

Valitse oikea palautumistapa

Sama virhekoodi kuvaa kahta eri tilannetta. Tarkista retryable ennen toimenpiteisiin ryhtymistä; pelkkä HTTP-tila ei kerro, pitääkö pyyntö yrittää uudelleen.

Eri syöte

Pyyntö on edelleen käsiteltävänä

Tässä esimerkissä on myös HTTP-vastausotsikko Retry-After: 1.

Pidä uudelleenyrityksen tunniste muuttumattomana

Niiden operaatioiden osalta, joiden dokumentaatiossa kuvataan idempotenssi, avain on rajattu organisaatioon, palvelutiliin, HTTP-metodiin, resurssipolkuun ja selvitettyyn API-versioon. Minkä tahansa näistä muuttaminen luo eri uudelleenyrityksen tunnisteen, eikä se palauta alkuperäistä operaatiota. Tunnistetietojen vaihtaminen saman palvelutilin alla ei muuta tätä tunnistetta, vaikka korvaavalla tunnistetiedolla on edelleen oltava käyttöoikeus. Säilytä alkuperäinen avain, runko, polku ja versio, kun palaudut aikakatkaisusta. Älä luo uutta avainta pelkästään ristiriidan ohittamiseksi: alkuperäinen kirjoitus on saattanut jo onnistua. Hae resurssi, kun sen tunnus on tiedossa, ja noudata operaation dokumentoitua palautumismenettelyä. Valmistunut uusinta sisältää Idempotent-Replayed: true, kun operaation dokumentaatiossa kuvataan vastauksen uusinta. Idempotency-Key -otsikon lähettäminen ei tee operaatiosta idempotenttia, ellei operaation viitedokumentaatiossa nimenomaisesti todeta kyseisen otsikon tukea. Uudelleenyritysten suoja on rajattu operaation säilytyskäytännön mukaan; se ei ole pysyvä takuu kaksoiskappaleita vastaan. Jos käsittely pysyy ratkaisematta, ota yhteyttä Living Securityn tukeen ja ilmoita request_id, UTC-aikaleima, metodi, polku ja API-versio. Älä koskaan liitä mukaan API-avainta, asiakassalaisuutta (client secret) tai käyttöoikeustunnusta (access token).