Skip to main content
A(z) /v1 API két egymástól független kéréskeretet alkalmaz. A kérés elutasításra kerül, ha bármelyik keret kimerült. A kulcsonkénti keret követi a kulcsot, bárhol is használják. Az IP-címenkénti keret az egyetlen keret a nem hitelesített forgalomra, a hitelesített forgalomra pedig egy második felső korlát.
A korlátokat a hitelesítés előtt érvényesíti a rendszer, ezért az érvénytelen vagy hiányzó hitelesítő adatokkal küldött kérések is a forrás keretébe számítanak. A pontos számszerű keretek üzemeltetői beállítástól függnek, és változhatnak; az alábbi válaszszerződés az a stabil felület, amelyre építeni érdemes.
A hitelesítéshez használja a Basic hitelesítő adatok bármelyik formáját – lásd: Gyorsindítás (apikey:secret vagy secret:). Állítsa a BASE értékét a szervezet regionális hosztjára – lásd: Régiók.

A 429-es válasz

Ha egy keret kimerül, az API 429 Too Many Requests választ ad vissza egy Retry-After fejléccel (másodpercben) és a szabványos problem-details törzzsel:
429 Too Many Requests
A válasz nem jelzi, hogy melyik keret merült ki. Minden 429 választ kezeljen ugyanúgy: várjon, majd próbálkozzon újra.

A 429-es válaszok kezelése

1

A Retry-After fejléc betartása

Az újrapróbálkozás előtt várjon legalább a Retry-After fejlécben megadott számú másodpercet. A korábbi újrapróbálkozás csak olyan kérésekkel emészti fel újra a keretet, amelyeket a rendszer úgyis elutasít.
2

Exponenciális visszalépés ismétlődő hibáknál

Ha az újrapróbálkozást ismét elutasítják, növelje a várakozási időt, és adjon hozzá véletlenszerű jittert, hogy a párhuzamos munkafolyamatok ne egyszerre próbálkozzanak újra. A kiszolgáló Retry-After értékét soha ne rövidítse le egy helyi korláthoz igazodva. Ha a kiszolgáló hosszabb várakozást kér, mint amennyit az újrapróbálkozási kerete megenged, hagyja abba, és ütemezze a feladatot későbbre.
3

A kérések sebességének egyenletesen tartása

Részesítse előnyben az egyenletes kérési sebességet a löketszerű terheléssel szemben. Tömeges olvasásnál használja a maximális lapméretet (limit=500), hogy a gyűjteményt kevesebb kéréssel fedje le – lásd: lapozás. Ha több listabejárás fut párhuzamosan (például Power BI táblák), tartsa mérsékelten a párhuzamosságot, és vegye figyelembe a Retry-After fejlécet, hogy egy átmeneti 429-es válasz ne akassza meg a teljes frissítést.
Ez a példa csak a 429 válaszok esetén próbálkozik újra GET kérésnél, legfeljebb öt kísérlettel és a kísérletek között legfeljebb 60 másodperc várakozással. Más hibáknál azonnal leáll. A hálózati időtúllépések eljutnak a hívóhoz. Az időtúllépéseket és az újrapróbálkozási kereteket a saját munkaterheléséhez igazítva állítsa be. A(z) requests az olvasási időtúllépést az adatfogadás közbeni maximális tétlenségi időként értelmezi, nem pedig teljes határidőként. Töltse be a LIVING_SECURITY_API_KEY értékét a titokkezelőjéből. A példa futtatása előtt telepítse a következőt: requests. A használatához hívja meg a következőt: get_with_retry("/organization").
Python
Ne másolja ezt a ciklust írási művelet köré. Az írás utáni időtúllépés azt is jelentheti, hogy a kiszolgáló még a kapcsolat megszakadása előtt véglegesítette a műveletet. Írást csak akkor ismételjen meg, ha az adott művelet referenciája kifejezetten dokumentálja az idempotenciát, és ugyanazt a kulcsot és adattartalmat használja. Ellenkező esetben az újrapróbálkozás előtt egyeztesse az erőforrás állapotát.

Ajánlott frissítési ütemezés

A frissítési gyakoriságot a kulcs kerete és a lapméret alapján méretezze. Egy nagy gyűjtemény teljes előzményeinek betöltése egyszeri költség; az állandósult állapotú frissítésekhez részesítse előnyben az inkrementális időablakokat, hogy minden futás jóval a keret alatt maradjon. A következőt mindig állítsa be explicit módon: limit=500 – az alapértelmezett 25 megsokszorozza a kérések számát.