Skip to main content
Rozhraní API /v1 uplatňuje dva nezávislé rozpočty požadavků. Požadavek je odmítnut, pokud je vyčerpán kterýkoli z nich. Rozpočet na klíč se vztahuje na klíč všude, kde je použit. Rozpočet na IP adresu je jediným rozpočtem pro neověřený provoz a druhým limitem pro ověřený provoz.
Limity se uplatňují před ověřením, takže požadavky s neplatnými nebo chybějícími přihlašovacími údaji se také započítávají do rozpočtu zdroje. Přesné číselné hodnoty rozpočtů nastavuje provozovatel a mohou se změnit; specifikace odpovědi uvedená níže je stabilní rozhraní, na které se lze při vývoji spolehnout.
Ověřte se pomocí libovolného tvaru přihlašovacích údajů Basic – viz Rychlý start (apikey:secret nebo secret:). Nastavte BASE na regionální hostitele organizace – viz Regiony.

Odpověď 429

Pokud je rozpočet vyčerpán, rozhraní API vrátí 429 Too Many Requests s hlavičkou Retry-After (v sekundách) a standardním tělem problem-details:
429 Too Many Requests
Odpověď neuvádí, který rozpočet byl vyčerpán. S každou odpovědí 429 zacházejte stejně: počkejte a poté požadavek zopakujte.

Zpracování odpovědí 429

1

Respektujte hlavičku Retry-After

Před opakováním počkejte alespoň tolik sekund, kolik je uvedeno v hlavičce Retry-After. Dřívější opakování pouze znovu spotřebovává rozpočet na požadavky, které budou odmítnuty.
2

Při opakovaných neúspěších exponenciálně prodlužujte prodlevu

Pokud je opakovaný požadavek znovu odmítnut, prodlužte prodlevu a přidejte náhodný jitter, aby paralelní workery neopakovaly požadavky současně. Nikdy nezkracujte hodnotu Retry-After ze serveru kvůli místnímu limitu. Pokud server požaduje delší čekání, než umožňuje váš rozpočet na opakování, přestaňte a naplánujte danou úlohu na později.
3

Vyrovnejte frekvenci požadavků

Dávejte přednost rovnoměrné frekvenci požadavků před nárazovými dávkami. Při hromadném čtení použijte maximální velikost stránky (limit=500), abyste kolekci pokryli menším počtem požadavků – viz stránkování. Pokud paralelně probíhá několik průchodů seznamy (například tabulky Power BI), udržujte souběžnost na mírné úrovni a respektujte Retry-After, aby dočasná odpověď 429 nezpůsobila selhání celé aktualizace.
Tento příklad opakuje pouze odpovědi 429 pro požadavek GET, nejvýše pětkrát a s čekáním nejvýše 60 sekund mezi pokusy. Při jiných chybách se ihned zastaví. Síťové časové limity se předávají volajícímu. Časové limity a rozpočty opakování nastavte podle své zátěže. requests chápe časový limit čtení jako maximální dobu nečinnosti při přijímání dat, nikoli jako celkovou lhůtu. Načtěte LIVING_SECURITY_API_KEY ze svého správce tajných klíčů. Před spuštěním tohoto příkladu nainstalujte requests. Pro jeho použití zavolejte get_with_retry("/organization").
Python
Tuto smyčku nekopírujte kolem operace zápisu. Časový limit po zápisu může znamenat, že server zápis potvrdil dříve, než spojení selhalo. Zápis opakujte pouze tehdy, když referenční dokumentace dané operace výslovně uvádí idempotenci, a to se zachováním stejného klíče a stejných dat. Jinak před dalším pokusem zjistěte aktuální stav zdroje.

Doporučený plán aktualizací

Frekvenci aktualizací přizpůsobte rozpočtu svého klíče a velikosti stránky. Úplné načtení celé historie velké kolekce je jednorázový náklad; pro běžné aktualizace dávejte přednost přírůstkovým oknům, aby každé spuštění zůstalo hluboko pod rozpočtem. Vždy explicitně nastavte limit=500 – výchozí hodnota 25 násobně zvyšuje počet požadavků.