Vi i Digitaliseringsdirektoratet har tatt kontakt med nokon av våre kontakter for råd om kvar ein finn slike data, og du høyrer forhåpentlegvis meir her i denne diskusjonstråden i løpet av eit par dagar.

| Hendelse: Digdir sine tilbud — webinar 16.03.2023 |

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

@johanna-drageset Jeg jobber i Digitaliseringsdirektoratet (Digdir) med blant annet Datahotellet (hotell.difi.no) og bistår Landbruksdirektoratet med å legge ut datasett på Datahotellet. Har sett nærmere på dette, og det ser ut til at nyeste versjonen av datasettet inneholder dataene du spørr etter. Ny versjon av datasettet ble nettopp lagt ut, etter noe forsinkelse på vår side. Det kan være at hvor mye som er gitt i tilskudd først kommer med i siste versjon av datasettet som blir publisert på nyåret. Dette kan gjerne Landbruksdirektoratet avklare.

Dette er en automatisk opprettet kommentartråd for datasettet Produksjons- og avløsertilskudd til jordbruksforetak – søknadsomgang 2022.

Dette er en automatisk opprettet kommentartråd for datatjenesten Arbeidsplassen.

Ein innleia med at vi vart kjent med Tadata via Datalandsbyen.
Legg på eit par lenker til relevante trådar:

• Hva er egentlig et API?
• Hvorfor er god API dokumentasjon så vanskelig?
• Tadata.no (eksempel på bruk av data)

@jostein @Tuva Kan de fortelje litt om kva som er nytt på tadata.no sidan de lanserte? Post gjerne i denne tråden i ny og ne når de lagar ny funksjonalitet eller noko slikt — gjerne eit skjermbilde eller to. Interessant å følgje med på!

Slenger på lenke til Kode24-artikkelen om Tadata som de nemde i dagens fagleg-arena-møte.
«Lager helt ny oversikt over norske API-er» 30.08.2021

Takk for deling! Kanskje til nytte for å tekste og legge ut fleire møter, webinarer og liknande. Skal tipse kollegaer internt i Digdir.

Såg artikkel i Digi.no om liknande arbeid ved Universitetet i Oslo (UiO).
17.02.2023: «Bygde tjeneste som sparer dem for 20 millioner i året: − Dette er ny og sjokkerende teknologi» (krev abonnement)

Dei skryt av at dei utvikla dette på rekordtid fordi Whisper er gjort tilgjengeleg som open kjeldekode, og at tekstane som blir generert frå lyd er på eit mykje høgare nivå enn med tidlegare løysingar, og handterer dialekter godt.

Korleis er køyretida på dette når ein køyrer lokalt på eiga maskin?

No kl. 13:00 legg vi om nettstaden https://hotell.difi.no/
For brukarane skal ein ikkje merke nokon forskjell.

Kjeldekoden for nettstaden er no å finne på GitHub, og nettstaden blir servert via Github Pages. Merk at dette kun er nettstaden der ein kan lese dokumentasjon, driftsmeldingar og navigere i datasett. Sjølve datahotellet (nåast på adresser som begynner med hotell.difi.no/api/) er ein eigen komponent som ikkje er berørt av dette.

Nettstaden hotell.difi.no har opp mot 100 besøkande kvar dag. Datahotellet sitt API har mange fleire treff.

Bakgrunnen er at nettstaden har køyrt på Drupal 7 som no skal fasast ut til fordel for nyare versjonar av Drupal, som til dømes digdir.no allereie køyrer på. For hotell.difi.no fann vi ut at det beste var å konvertere til statiske nettsider.

No blir det også mogeleg å gje tilbakemeldingar på nettstaden, enten det er funksjonalitet i å bla i datasett eller dokumentasjonen, ved å legge inn issues i GitHub, eller til og med foreslå endringar direkte i form av Pull Requests.