Bruke API med rate-limiting

[livar.bergheim]

Har du tips til korleis bruke eller sette opp integrasjonar mot API som har begrensing på kor mange kall du kan gjere mot API-et («rate-limiting»)?
Er det spesielle klient-bibliotek eller rammeverk som gjer jobben for deg, eller må du manuelt kode logikken for å handtere dette?

Det har nyleg blitt aktuelt sidan vi i Digdir vart nødt til å innføre rate-limiting på Datahotellet, og det er også andre API-er som har dette.

[leo.valen]

Det kommer helt an på typen endepunkt, brukstilfellet og klienten. Fra klientsiden må det alltid tas høyde for rate limiting på en eller annen måte, for eksempel ved å vise en feilmelding. Klienten må også ta høyde for cache-headere for å ikke sende forespørsler til data som allerede er lastet ned.

Rate limiting er ment å begrense misbruk fra klientsiden, så man bør ta høyde for alle «godsinnede» klienter og skalere for all legitim bruk. Det er viktig å unngå at rate limiting ikke hindrer legitim bruk.

Det gir ofte mening å skille på typen data og hvor ofte den oppdateres, og å bruke en cache eller CDN for å avlaste back-end hvis forespørslene gjelder forhåndsgenerert data.

[livar.bergheim]

@leo-valen Takk for tipsa. Tenker konkret på kun korleis handtere rate-limiting. Å lage klientar som respektere cache-headerar (til dømes ETag) kan vi setje som premiss.

La oss seie at ein skal gjere 10 kall mot hotell.difi.no.
Dersom ein fyrer av alle kalla i eit jafs, går ein over grensa på 5 forespørslar i sekundet, og ein får feilmelding på halvparten og ein sit igjen med berre deler av dataene.
Ein (for) enkel måte å handtere dette er å automatisk prøve på nytt dersom ein får feilkode 429 (HTTP-statuskode «Too many requests») tilbake. Det fører til mange mislykka kall før ein kjem i mål med alle 10 kalla. For serveren er det langt mindre belastande å avvise for mange kall enn om serveren ikkje hadde hatt rate-limiting og måtte handtere mange kall i eit jafs. Det blir likevel ein del unødige kall med denne framgangsmåten.

Fann ein artikkel som går igjennom ulike strategiar for å handtere dette:
https://www.useanvil.com/blog/engineering/throttling-and-consuming-apis-with-429-rate-limits/

Grunnen til det opprinnelege spørsmålet er behovet for ein som utviklar å sleppe å forhalde seg til kompleksiteten med å handtere dette. Ideelt sett vil ein ha eit bibliotek som hjelper med dette slik at ein i koden berre kan oppgje kva kall som skal gjerast, og så handterer biblioteket rate-limiting og svar tilbake.

Alternativ: laste ned heile datasettet
I tilfellet med datahotellet, får ein ut data med 100 rader pr. API-kall (paginering). Dersom ein vil hente ein stor del av datasettet, og datasettet ikkje er så stort, bør ein vurdere å heller hente ned heile datasettet. Er det f.eks. under 20 MB, så kan det fungere fint å hente ned også i klientside-kode som køyrer i nettlesaren til sluttbrukaren. Å laste ned heile datasettet i eitt kall er kun tilgjengeleg i CSV-format.

Gjorde dette sjølv for eit par år sidan i eit hobbyprosjekt (søk på «$.csv»). Riktignok eit eldre programvarebibliotek (jQuery-plugin). Det fungerte svært bra. Nettlesaren handterte då cache-mekansimen (ETag) slik at datasettet (ca. 5 MB) ikkje vart lasta ned på nytt med mindre det var ein ny versjon av datasettet.