Datalandsbyen Logo

    Datalandsbyen

    • Kategorier
    • Emneord
    • Siste
    • Populære
    • Kalender
    • Lenkeikon
    • Søk
    • Varslinger Logg inn / Registrer
    Community illustrasjon

    Datalandsbyen

    Velkommen til nettforumet Datalandsbyen! Vi er glade for at du har funnet frem til oss.

    Her kan du stille spørsmål om alt du måtte lure på om deling og bruk av data, eksempelvis datasett, API-er, begreper, informasjonsmodeller og juss, videre kan du delta i diskusjoner, vise frem prosjektene dine, knytte nye kontakter og finne nye samarbeid. Nettforumet er åpent for alle, men for å skrive innlegg må du først registrere deg. Formålet med forumet er å legge til rette for at data skal bli en verdiskapende ressurs for hele samfunnet – bli med og bidra til økt kunnskap, åpenhet og innovasjon. Vi oppfordrer til en konstruktiv og saklig dialog i nettforumet.

    Bruke API med rate-limiting

    Tips og spørsmål
    2
    3
    268
    Laster flere innlegg
    • Eldste til nyeste
    • Nyeste til eldste
    • Flest stemmer
    Denne tråden har blitt slettet. Bare brukere med trådhåndterings-privilegier kan se den.
    • L
      livar.bergheim sist endret av

      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.

      1 Svar Siste svar Svar Siter 0
      • L
        leo.valen sist endret av

        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.

        L 1 Svar Siste svar Svar Siter 0
        • L
          livar.bergheim Svar til @leo.valen sist endret av

          @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.

          1 Svar Siste svar Svar Siter 0
          Ikon Svar
          Ikon Logg inn for å besvare
          • Første innlegg
            Seneste innlegg
          • Datalandsbyen Logo
          • Våre partnere
          • Felles datakatalog Åpne
          • Datafabrikken Åpne
          • Transportportal Åpne
          • Om nettstedet
          • Digitaliseringsdirektoratet forvalter datalandsbyen.
          • Samtykke og brukervilkår
          • Personvernerklæring Åpne
          • Informasjonskapsler Åpne
          • Tilgjengelighetserklæring Åpne
          • Kontakt
          • Lenkeikonfellesdatakatalog@digdir.no