/v1 listavégpont ugyanazt a burkolót adja vissza, és ugyanúgy lapoz:
tokenalapon, csak előre haladva.
A listaburkoló
string
Értéke mindig
"list".array
Az erőforrások oldala, stabil, determinisztikus sorrendben.
string | null
Ezt adja meg
page_token értékként a következő kérésben, hogy lekérje a soron következő oldalt.
null, ha nincs több találat.boolean
Azt jelzi, hogy az aktuális oldalon túl léteznek-e további találatok.
Kérésparaméterek
integer
alapértelmezett:"25"
Oldalméret. 1 és 500 közötti egész szám. Az ezen a tartományon kívüli értékek
400 hibát eredményeznek invalid_request kóddal.string
Az előző válasz
next_page_token értéke. Az első oldalnál hagyja el.Kivétel:
GET /v1/cohorts/{id}/members oldalanként legfeljebb 50 sort ad vissza,
akkor is, ha magasabb limit értéket kér. A has_more és a
next_page_token továbbra is a Kohorsz tényleges hátralévő részét tükrözi.apikey:secret vagy secret:).
Állítsa a BASE értékét a szervezet regionális gazdagépére – lásd a
Régiók című oldalt.
Lista bejárása
Töltse be aLIVING_SECURITY_API_KEY értékét a titokkezelőből, ahogyan a gyorsindítási útmutatóban is szerepel.
Ehhez a példához entity:read szükséges; az első kérés útmutatójában használt kulcshoz
lehet, hogy ezt a további jogosultságot is meg kell adni. Telepítse a requests csomagot a Python-, illetve a jq eszközt a shellpéldához.
Mindkét példa rögzített verziót használ, változatlanul hagyja a szűrőket, és elutasítja az
átirányításokat. Hiba esetén, valamint 1000 oldal után leállnak ahelyett, hogy egy részleges
bejárást teljesként jelentenének. A Python olvasási időtúllépése az inaktivitást korlátozza,
nem a feladat teljes időtartamát; az integrációban határozzon meg határidőt a feladatra.
Addig kérje le az oldalakat, amíg a next_page_token értéke null nem lesz. Tömeges
olvasásnál részesítse előnyben a limit=500 beállítást, hogy kevesebb kéréssel fedje le a gyűjteményt – lásd a
sebességkorlátokat.
Tartsa stabilan a szűrőket lapozás közben
Az oldaltokenek átlátszatlan, aláírt kurzorok. Minden token kötődik a szervezethez, a hitelesített szolgáltatásfiókhoz, a szerződésverzióhoz, valamint az azt létrehozó kérés pontos szűrőkészletéhez. Ha ezek bármelyikét bejárás közben megváltoztatja – például a második oldalon hozzáad egytype szűrőt –, a válasz 400 hiba lesz invalid_request
kóddal a page_token paraméteren:
400 Invalid request
A listavégpontok elutasítják a nem támogatott lekérdezési paramétereket egy
400
invalid_request hibával, amely megnevezi a paramétert. A támogatott szűrőket az egyes végpontok referenciájában ellenőrizheti.Megszakadt vagy változó gyűjtemény kezelése
Ezek a példák nem próbálják újra automatikusan a hibákat.429 esetén vegye figyelembe a Retry-After értékét,
és kövesse a korlátozott újrapróbálkozási útmutatót. Olvasás újrapróbálásakor
tartsa meg ugyanazt a régiót, szolgáltatásfiókot, verziót, szűrőket és az utolsó sikeresen feldolgozott
oldaltokent. A hitelesítő adatok cseréje nem biztosít hozzáférést:
minden kérés az aktuális jogosultságokat ellenőrzi.
A többoldalas olvasás nem pillanatkép a gyűjteményről. A sorok a bejárás során megváltozhatnak.
Az erőforrásokat a stabil id azonosítójuk alapján dolgozza fel, és tegye idempotenssé a további
írásokat; újraindítás után egy sor ismét megjelenhet. Ha egy tokent elutasít a rendszer,
vizsgálja meg a page_token hibát, és javítsa a kérést, mielőtt az első oldalról újraindítja a bejárást.
Ne dobja el csendben a korábban feldolgozott adatokat, és ne jelöljön megszakadt exportálást befejezettnek.
Pontos jelentési összesítésekhez használja a megfelelő jelentési erőforrást, ne pedig egy élő listabejárást tekintsen pillanatképnek.
