<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Bruke API med rate-limiting]]></title><description><![CDATA[<p dir="auto">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»)?<br />
Er det spesielle klient-bibliotek eller rammeverk som gjer jobben for deg, eller må du manuelt kode logikken for å handtere dette?</p>
<p dir="auto">Det har nyleg blitt aktuelt sidan vi i Digdir vart nødt til å <a href="https://datalandsbyen.norge.no/topic/179/datahotellet-ustabilt-mars-2022-rate-limiting-innf%C3%B8rt">innføre rate-limiting på Datahotellet</a>, og det er også <a href="https://datalandsbyen.norge.no/topic/149/elma-for-alle-norske-bedrifter/6">andre API-er</a> som har dette.</p>
]]></description><link>https://datalandsbyen.norge.no/topic/184/bruke-api-med-rate-limiting</link><generator>RSS for Node</generator><lastBuildDate>Tue, 14 Apr 2026 12:09:35 GMT</lastBuildDate><atom:link href="https://datalandsbyen.norge.no/topic/184.rss" rel="self" type="application/rss+xml"/><pubDate>Mon, 04 Apr 2022 17:05:05 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Bruke API med rate-limiting on Fri, 10 Mar 2023 09:59:02 GMT]]></title><description><![CDATA[<p dir="auto">@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.</p>
<p dir="auto">La oss seie at ein skal gjere 10 kall mot <a href="http://hotell.difi.no" rel="nofollow ugc">hotell.difi.no</a>.<br />
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.<br />
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.</p>
<p dir="auto">Fann ein artikkel som går igjennom ulike strategiar for å handtere dette:<br />
<a href="https://www.useanvil.com/blog/engineering/throttling-and-consuming-apis-with-429-rate-limits/" rel="nofollow ugc">https://www.useanvil.com/blog/engineering/throttling-and-consuming-apis-with-429-rate-limits/</a></p>
<p dir="auto">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.</p>
<p dir="auto"><strong>Alternativ: laste ned heile datasettet</strong><br />
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.</p>
<p dir="auto">Gjorde dette sjølv for eit par år sidan i eit <a href="https://github.com/livarb/turbo-chrome-ext/blob/master/datahotellFrontpage.js" rel="nofollow ugc">hobbyprosjekt</a> (søk på «$.csv»). Riktignok eit eldre <a href="https://github.com/evanplaice/jquery-csv" rel="nofollow ugc">programvarebibliotek (jQuery-plugin)</a>. Det fungerte svært bra. Nettlesaren handterte då cache-mekansimen (ETag) slik at <a href="https://hotell.difi.no/?dataset=difi/datahotell/sidevisninger-pr-datasett" rel="nofollow ugc">datasettet</a> (ca. 5 MB) ikkje vart lasta ned på nytt med mindre det var ein ny versjon av datasettet.</p>
]]></description><link>https://datalandsbyen.norge.no/post/682</link><guid isPermaLink="true">https://datalandsbyen.norge.no/post/682</guid><dc:creator><![CDATA[livar.bergheim]]></dc:creator><pubDate>Fri, 10 Mar 2023 09:59:02 GMT</pubDate></item><item><title><![CDATA[Reply to Bruke API med rate-limiting on Tue, 12 Apr 2022 19:37:13 GMT]]></title><description><![CDATA[<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
]]></description><link>https://datalandsbyen.norge.no/post/411</link><guid isPermaLink="true">https://datalandsbyen.norge.no/post/411</guid><dc:creator><![CDATA[[[global:former-user]]]]></dc:creator><pubDate>Tue, 12 Apr 2022 19:37:13 GMT</pubDate></item></channel></rss>