Paginering och hastighetsbegränsningar i API-anrop

API:er returnerar sällan tusentals poster i ett enda svar. I stället delar de upp resultaten i sidor. Om arbetsflödet bara läser det första svaret missar det obemärkt större delen av datan.

Genom att hantera pagination ser du till att allt hämtas.

Pagination innebär att en stor resultatmängd delas upp i mindre delar som kallas sidor. Varje API-anrop returnerar en sida samt en anvisning om hur nästa sida hämtas.

Arbetsflödet loopar och begär sidor tills det inte finns fler.

En vanlig variant använder offset och limit. Limit anger hur många poster varje sida innehåller, medan offset anger hur många poster som ska hoppas över.

För att läsa sida två med en limit på 50 begär du offset 50. Sida tre använder offset 100 och så vidare.

Vissa API:er är ännu enklare: du anger ett page number och en sidstorlek. Begär sida 1, sedan sida 2 och fortsätt att öka numret tills svaret är tomt.

En tom sida visar att du har nått slutet.

Moderna API:er använder ofta en cursor: varje svar innehåller en token som pekar på nästa sida. Du skickar med den token i nästa begäran.

Cursorer förblir stabila även när data ändras mellan anropen, vilket gör dem mer tillförlitliga än offset.

I en automatisering innebär pagination vanligtvis en loop: gör ett anrop, behandla sidan, kontrollera om det finns en nästa sida eller cursor och upprepa tills du är klar.

Vissa plattformar har en inbyggd inställning för pagination. Annars bygger du loopen manuellt med en repeater-modul.

En rate limit begränsar hur många begäranden du får göra under en viss tidsperiod – till exempel 60 anrop per minut. Om du överskrider gränsen avvisar API:et fler anrop, vanligtvis med felet 429 Too Many Requests.

Hastighetsbegränsningar skyddar API:et mot överbelastning.

Många API:er returnerar headers som visar din status, till exempel hur många begäranden som återstår och när tidsfönstret återställs.

Genom att läsa dessa kan arbetsflödet sakta ner innan det blockeras, i stället för efteråt.

Det enklaste sättet att hålla sig under en gräns är att lägga in en kort fördröjning mellan anropen. Om du får göra ett anrop per sekund håller en paus på en sekund i loopen dig inom gränsen.

Fördröjningar innebär lite lägre hastighet men ökad tillförlitlighet.

När du faktiskt når en gräns returnerar API:et 429, ofta med värdet Retry-After som anger hur länge du ska vänta. Ett robust arbetsflöde väntar så länge och försöker sedan igen.

Detta beteende med backoff förhindrar en kedjereaktion av misslyckade anrop.

Så här hämtar du stora datamängder på ett tillförlitligt sätt:

• Använd alltid paginering – anta aldrig att ett anrop returnerar allt
• Lägg till fördröjningar för att hålla dig inom hastighetsgränserna
• Följ Retry-After och använd backoff vid 429
• Begär endast de fält och sidstorlekar du behöver

Du har lärt dig att hantera paginering och hastighetsgränser:

• Använd paginering för att hämta fullständiga resultatmängder med hjälp av offset, sidnummer eller cursor
• Gå igenom sidorna tills det inte finns fler
• Hastighetsgränser begränsar antalet anrop per tidsintervall. Om du överskrider dem returneras 429
• Lägg till fördröjningar, läs gränsrubriker och följ Retry-After för att använda backoff

Med dessa metoder förblir dina API-automatiseringar kompletta och oblockerade.