Tips og spørsmål

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

Hei Espen, Ja, vi erfarer også at API tilbydere sliter med å dokumentere på en måte som gjør at brukeren både forstår hvilken data de får tilgang til og hvordan man rent teknisk skal implementere. Vi ser mange eksempler på at tilbydere prøver å gjøre begge deler i samme dokumentasjon, hvilket ofte fører til at hverken dataen(produktet) eller implementasjonen blir enkel å forstå. Jeg opplever nok ikke at våre brukere stiller like høye krav til dokumentasjon som det du beskriver over. Det er selvsagt behov for å forstå hvor dataen kommer fra, hva betingelsene for å bruke den er og hvordan man kan implementere mot den, men vi opplever at skoen trykker mest på det å enkelt kunne få en oversikt og forstå hva man får tilgang på, også for en person som ikke nødvendig vis er utvikler. I Tadata fokuserer vi på at det skal bli enkelt for brukere å sette seg inn i hvilken data som ligger bak et gitt API og hva som skal til for å få tilgang til den. Vi har laget en testfunksjon som gjør at brukere kan kjøre spørringer direkte i nettleser med input fra enkelt forståelige felter, og opplever at dette blir mye brukt og er av stor verdi. En litt enklere og mer praktisk tilnærming til dokumentasjon kan man vel kanskje si. Kanskje er dette noe man kan benytte seg av på toppen av mer omstendelig dokumentasjon i det offentlige også?

@andrea Vi har dessverre ikke noe åpen kildekode, men det er bare å komme med ønsker, så skal vi absolutt vurdere det i den videre utviklingen! Angående å hente ut mer data i ett kall og gjennomsnittspris, er dette noe som flere har kommet med forslag om, så det står allerede på todo-listen

Ja, jeg tenker meg et sted der vi kan ha kontoer som https://twitter.com/Regjeringen, https://twitter.com/datakatalogen, https://twitter.com/Trondheim, https://twitter.com/ssbnytt, https://twitter.com/Arkivverket, https://twitter.com/VegvesenMidt og https://twitter.com/VegvesenData. ... (Sånn i parentes ser jeg også gjerne at noen av skattepengene mine brukes til støtte til sosiale medier for befolkningen, f.eks. ved å drifte egne tjenere eller noe lignende pressestøtte, men det er en mye større oppgave og en mye større diskusjon.)

Vi i DFØ har sett på DCAT og Purview, se kildekoden: https://github.com/dfo-no/ads-datakatalog. På toppen har vi laget en datakatalog, se https://data.dfo.no/. Vi har gjenbrukt mye av arbeidet til Digdir, se https://github.com/Informasjonsforvaltning/atlasdcat. Digdir jobber i dag med å lage en atlas-plugin som man kan bruke sammen med Purview-løsningen.

@oystein-asnes takk for informasjon! DCAT-AP-NO for CKAN komponenten ser bra ut. Hvis det skulle være an ny versjon av DCAT-AP-NO i nær framtida, det er bedre å vente for det. I mellomtiden skal jeg forske komponenten og hva kan være lagt til den.

Vi vil bare minne om at fristen for å kommentere er 28. oktober 2022. Bruk gjerne denne tråden i Datalandsbyen til å diskutere.

Oppdatering 06.07.22: Vi har nå funnet våre to første hospitanter, men tar gjerne imot meldinger fra kandidater som kan ha interesse i en eventuell utvidelse av antallet hospitanter på et senere tidspunkt.

En kjapp presisering: For riksveger kan vegeier være enten Statens vegvesen eller Nye veier. Denne forskjellen er ikke beskrevet i dette datasettet.

@filip-hansen Jepp, bare at denne NULL-episoden faktisk skjedde. Evt. denne klassikeren som går under kategorien "godt forsøk" https://hackaday.com/2014/04/04/sql-injection-fools-speed-traps-and-clears-your-record/

@Jim-J-Yang Dere har ikke laget en slik mal for Tjenester-beskrivelse også vel? Hmmm. Det er vel den CPSV-AP-NO det ja. Jeg har en i mitt hus som gjerne vil se på denne, så en oversendelse er helt ok.

@anette-skurdal Så hyggelig! Her er det bare å låne og dele i vei.