/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.
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 API429 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
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.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
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.
