Data och API:er

tove

största problemet inte har att göra med att dela data utan att kvaliteten när datan väl delas

Håller med till viss del. Data governance eller arbetssätten för att jobba med både data och kod som data är ett stort problem. Men jag tycker inte dålig kvalitét är anledning till att inte dela data, så länge man är transparent om det.

Men jag kan tänka mig hellre öppna datamängder utan säkerställd kvalitet delas öppet om man är transparent och hellst kan bidra till kvalitén som datakonsument dvs en öppen governance form.

Tar hellre öppen data utan säkerställd kvalitét än bakom betalvägg och bli besviken på tillgängligheten, specifikationen eller formen och möjligheten att påverka detta. Säg att det är svinbra kvalitét (uppdaterad) på data från producent X men de följer inte standarder från EU:s öppna data set så du måste alltid göra en workaround för att få de att lira. Då betalar du för datamängden och betalar i tid att dina utvecklare alltid måste hantera problemet.

Och i vissa fall är data utan kvalitét det viktigaste test och de som exprimenterar om metoder och arbetssätt kräver sällan kvalitétsstämplad data. Exempelvis har api för testpersonnummer underlättat arbetet med testmiljöer extremt. Önskar att det skulle funnits när jag jobbade med webb. Ska kolla om samma datamängder finns för dummy användare.

Dennis_Priskorn

@tove sa i Data och API:er:

Detta exempel går ju att ta mer tekniskt och i all oändlighet. Vad det innebär för datakonsumenten om api är inbyggt i system och dataproducenten gör förändringar utan att meddela. Exempelvis byter benämning på datatabellen "postadress" till "gatuadress" eller format på datatabellen "personnummer" från "ÅÅMMDD-nnnn" till "XXÅÅMMDDnnnn" och hur man kan ha en "landing"-databas för redundans för att sådant inte ska innebära driftstörning eller om det ska hämtas av webbplats för att utvecklarna ska kunna modulera data och bygga självständigt så det blir en stabil webbplats, men utan att va tvungna att bygga externa api.

Det här går att lösa med versionering. Jag versionerar API:n jag skriver just nu. Datamängder kan också versioneras så att man enkelt kan peka på just den version som laddats ner.

@Magnus-Sälgö och jag vill ha ändringsström också och det har jag då aldrig sett någon offentlig myndighet erbjuda.

jonass

@Dennis_Priskorn Ändringsström avseende data: https://data.arbetsformedlingen.se/rss/datajobtechdevse.xml i beta version.

Dennis_Priskorn

@jonass sa i Data och API:er:

@Dennis_Priskorn Ändringsström avseende data: https://data.arbetsformedlingen.se/rss/datajobtechdevse.xml i beta version.

Hallå! Jobtechdev håller kvar ledartröjan ser jag Jag har bara jobbat med Wikimedias ditto som är baserat på en ström från Kafka.

Nina_Berlin

@tove Tack för ditt svar! Mycket välformulerat och relevant. Jag tolkar det som att det ligger i linje med min känsla av att vi får nytta av data när vi kan förstå datat så det kan bilda information, och det kan man göra på olika sätt, bland annat genom att använda API:er. Det som är mest praktiskt beror troligen på vad datamängden kan bilda för information.

Jag pratade vidare om frågan internt på DIGG med bl a @Kristine_ och insåg efter det samtalet att visst data är svårt att ta till sig utan API:er. Om man vill använda realtidsdata från t ex IoT-givare är det mer praktiskt att ha tillgång till det via ett API, eftersom datat uppdateras hela tiden. Det är fortfarande datat man är ute efter, nyttan med API:et ligger ju i vilket data man når med det.

Nina_Berlin

@tove Jag tycker att det att man delar sitt data är första stegen på vägen till att höja kvaliteten på det. Hur ska man annars förstå vad man behöver ändra på? Vi behöver alla feedback.

tove

@Dennis_Priskorn sa i Data och API:er:

Det här går att lösa med versionering. Jag versionerar API:n jag skriver just nu. Datamängder kan också versioneras så att man enkelt kan peka på just den version som laddats ner.

Absolut, jag lyfte det mer för att påtala att det inte är löst bara för att man har ett api utan transparensen och kommunikationen kring specifikation och förändringar behövs ändå. Att om API versioneringen slår till blir det ett "tillbud" istället för en olycka. Men API versionering bör ju inte vara ända åtgärden.

Och sedan är väl versionering en utvecklingsåtgärd i antingen lifecycel eller ad hoc behov, om det inte ska vara en allt för bred tratt initialt?

Tänker att om du versionerar api utan att veta vad du garderar för så bör du öka din attackyta för i vart fall vissa API attacker och även kanske för DDoS som inriktar sig mot endpoints? Men nu spekulerar jag utifrån konceptet. Jag är ju inte teknisk i grunden och API versionering är inte det område jag är starkast på.

tove

@Nina_Berlin sa i Data och API:er:

realtidsdata från t ex IoT-givare är det mer praktiskt att ha tillgång till det via ett API, eftersom datat uppdateras hela tiden

Absolut! Och i sådana fall kan ett öppet test-api vara värt också eftersom det kan vara svårt att bygga och testa mot en statisk testdatabas.

Nina_Berlin

@tove Japp, vi borde ha fler sandboxes över huvud taget.

tove

@Nina_Berlin precis, men sen ser jag absolut att ett det behöver finnas fungerande effektiva feedbacklooper här för att inte några få ska drunkna, och i värsta fall de som också utvecklar.

Exempelvis kan första steget vara en feedback där man finner dataset till en mail eller ticketsystem av formulär som är utformat utefter dataspecifikationen och exempelvis har alternativen

Vad är ditt ärenden?

Föreslå ändring av data / rapportera fel
Bidra med ny data
Förfrågan om ytterligare data i datamängen

Det är ju främst 1 och 2 som behöver ha särskilda formulär för effektivitet. Exempelvis ser man i det jag lämnade in igår att de bara har en "your proposal". Om jag minns rätt förifyllde de dock de tre översta utefter vilken sida och browserinställning gissar jag.

De skulle ju kunna haft de tre eller fyra olika tabellerna som input-fält så skulle jag kunna lagt till förslag direkt i dom, anpassat utefter specifikationen. Eller om jag anger att det är ändring av data så dropdown på vilken tabell och vilken datarad. Så behöver bara ändringen va fritext.

(De efterfrågar även namn och e-post men jag klippte bort det här)