/v1 aplică două bugete de solicitări independente. O solicitare este refuzată
dacă oricare dintre bugete este epuizat.
Bugetul per cheie urmărește cheia oriunde este utilizată. Bugetul per IP este
singurul buget pentru traficul neautentificat și o a doua limită pentru traficul
autentificat.
Limitele sunt aplicate înainte de autentificare, astfel că solicitările cu
credențiale nevalide sau lipsă se contorizează, de asemenea, în bugetul sursei. Valorile numerice exacte ale
bugetelor sunt configurate de operator și pot fi modificate; contractul
răspunsului de mai jos este interfața stabilă pe care trebuie să vă bazați.
apikey:secret sau secret:).
Setați BASE la gazda regională a organizației — consultați
Regiuni.
Răspunsul 429
Când un buget este epuizat, API-ul returnează429 Too Many Requests cu un
antet Retry-After (în secunde) și corpul standard problem-details:
429 Too Many Requests
429
în același mod: așteptați, apoi reîncercați.
Gestionarea răspunsurilor 429
1
Respectați Retry-After
Așteptați cel puțin numărul de secunde din antetul
Retry-After înainte de
a reîncerca. O reîncercare mai devreme consumă din nou din buget pentru solicitări care vor fi
refuzate.2
Măriți exponențial intervalul de așteptare la repetări
Dacă o reîncercare este refuzată din nou, măriți intervalul de așteptare și adăugați un jitter aleatoriu
astfel încât procesele paralele să nu reîncerce sincronizat. Nu scurtați niciodată valoarea
Retry-After a serverului pentru a respecta o
limită locală. Dacă serverul vă cere să așteptați mai mult decât permite bugetul dvs. de reîncercări,
opriți-vă și programați lucrarea pentru mai târziu.3
Uniformizați rata solicitărilor
Preferați o rată constantă a solicitărilor în locul vârfurilor. Pentru citiri în masă, utilizați dimensiunea maximă
a paginii (
limit=500) pentru a acoperi colecția cu mai puține solicitări — consultați
paginare. Când mai multe parcurgeri de liste rulează în
paralel (de exemplu, tabele Power BI), păstrați un nivel moderat de concurență și respectați
Retry-After, astfel încât un 429 temporar să nu ducă la eșecul întregii reîmprospătări.429 pentru o solicitare GET, cu cel mult
cinci încercări și cel mult 60 de secunde de așteptare între încercări. Se oprește
imediat la alte erori. Expirările de timp de rețea sunt propagate către apelant. Configurați
expirările de timp și bugetele de reîncercări în funcție de volumul dvs. de lucru. requests interpretează timpul limită
de citire ca timpul maxim de inactivitate la primirea datelor, nu ca termen limită total.
Încărcați LIVING_SECURITY_API_KEY din managerul dvs. de secrete. Instalați requests
înainte de a rula acest exemplu. Apelați get_with_retry("/organization") pentru a-l utiliza.
Python
Program de reîmprospătare recomandat
Dimensionați frecvența reîmprospătării în funcție de bugetul cheii și de dimensiunea paginii. O încărcare istorică completă a unei colecții mari este un cost unic; preferați ferestre incrementale pentru reîmprospătările în regim stabil, astfel încât fiecare rulare să rămână cu mult sub buget. Setați întotdeaunalimit=500 în mod explicit — valoarea implicită de 25 multiplică numărul de solicitări.
