Skip to main content
/v1 API nodrošina divus neatkarīgus pieprasījumu limitus. Pieprasījums tiek noraidīts, ja ir izsmelts jebkurš no limitiem. Limits katrai atslēgai seko atslēgai visur, kur tā tiek izmantota. Limits katrai IP adresei ir vienīgais limits neautentificētai datplūsmai un otrs augšējais slieksnis autentificētai datplūsmai.
Limiti tiek piemēroti pirms autentifikācijas, tāpēc pieprasījumi ar nederīgiem vai trūkstošiem akreditācijas datiem arī tiek ieskaitīti avota limitā. Precīzus skaitliskos limitus konfigurē operators, un tie var mainīties; tālāk aprakstītais atbildes līgums ir stabilā saskarne, uz kuras balstīt izstrādi.
Autentificējieties, izmantojot jebkuru no Basic akreditācijas datu formātiem — skatiet Quickstart (apikey:secret vai secret:). Iestatiet BASE uz organizācijas reģionālo resursdatoru — skatiet Regions.

429 atbilde

Kad limits ir izsmelts, API atgriež 429 Too Many Requests ar Retry-After galveni (sekundēs) un standarta problem-details pamattekstu:
429 Too Many Requests
Atbildē nav norādīts, kurš limits ir izsmelts. Visas 429 atbildes apstrādājiet vienādi: uzgaidiet un atkārtojiet pieprasījumu.

429 atbilžu apstrāde

1

Ņemiet vērā Retry-After

Pirms atkārtošanas uzgaidiet vismaz tik sekunžu, cik norādīts Retry-After galvenē. Atkārtojot pieprasījumu ātrāk, tiek tikai velti tērēts limits pieprasījumiem, kas tiks noraidīti.
2

Atkārtojumu gadījumā izmantojiet eksponenciālo atkāpšanos

Ja atkārtotais pieprasījums tiek noraidīts vēlreiz, palieliniet atkāpšanās laiku un pievienojiet nejaušu novirzi (jitter), lai paralēlie darbinieki neatkārtotu pieprasījumus vienlaikus. Nekad nesaīsiniet servera norādīto Retry-After, lai pielāgotos lokālajam ierobežojumam. Ja serveris prasa gaidīt ilgāk, nekā pieļauj jūsu atkārtojumu limits, apturiet darbu un ieplānojiet to vēlākam laikam.
3

Izlīdziniet pieprasījumu ātrumu

Dodiet priekšroku vienmērīgam pieprasījumu ātrumam, nevis pārsprāgumiem. Lielapjoma nolasīšanai izmantojiet maksimālo lapas izmēru (limit=500), lai apstrādātu kolekciju ar mazāk pieprasījumiem — skatiet pagination. Ja vairāki sarakstu apgūšanas procesi darbojas paralēli (piemēram, Power BI tabulas), saglabājiet mērenu paralēlismu un ņemiet vērā Retry-After, lai īslaicīga 429 atbilde neizraisītu visa atsvaidzināšanas procesa kļūmi.
Šis piemērs atkārto tikai 429 atbildes GET pieprasījumam, ar ne vairāk kā pieciem mēģinājumiem un ne vairāk kā 60 sekunžu gaidīšanu starp mēģinājumiem. Citu kļūdu gadījumā tas apstājas nekavējoties. Tīkla noildzes tiek nodotas izsaucējam. Konfigurējiet noildzes un atkārtojumu limitus atbilstoši savai darba slodzei. requests interpretē lasīšanas noildzi kā maksimālo dīkstāves laiku datu saņemšanas laikā, nevis kā kopējo termiņu. Ielādējiet LIVING_SECURITY_API_KEY no sava noslēpumu pārvaldnieka. Pirms šī piemēra palaišanas instalējiet requests. Lai to izmantotu, izsauciet get_with_retry("/organization").
Python
Nekopējiet šo ciklu ap rakstīšanas operāciju. Noildze pēc rakstīšanas var nozīmēt, ka serveris to ir apstiprinājis, pirms savienojums pārtrūka. Atkārtojiet rakstīšanu tikai tad, ja attiecīgās operācijas atsaucē ir skaidri dokumentēta idempotence, saglabājot to pašu atslēgu un datu kopu. Pretējā gadījumā pirms atkārtošanas saskaņojiet resursa stāvokli.

Ieteicamais atsvaidzināšanas grafiks

Pielāgojiet atsvaidzināšanas biežumu savam atslēgas limitam un lapas izmēram. Lielas kolekcijas pilnā vēsturiskā ielāde ir vienreizējas izmaksas; ikdienas atsvaidzināšanai dodiet priekšroku inkrementāliem logiem, lai katra izpilde paliktu krietni zem limita. Vienmēr skaidri iestatiet limit=500 — noklusējuma vērtība 25 palielina pieprasījumu skaitu.