Loading…
Tilbage

OIOREST nyhedsbrev: Find din yndlingsbureaukrat - API


01-07-2010 13:59:31

Vores minister Charlotte Sahl-Madsen, som for ikke så lang tid siden har rundet de første 100 dage på ministerkontoret, har besluttet at Videnskabministeriet (VTU) skal udstille alle vores ikke sikkerhedsbelagte data: ” … at vi på mit område tager vores egen medicin ved at gå foran og i løbet af i år at åbne op for og udstille alle vores datasæt, som ikke er omfattet af fortroligheds- eller privacymæssige begrænsninger.”. Et rigtigt godt initiativ, som har skabt en del aktivitet i VTU. Datajægerne har udover deres sædvanlige datajagt ud af huset også jaget data internt. De forskellige kontorer i VTU regi har undersøgt, hvilke data de ligger inde med. Martin Høegh Mortensen, Martin Ege Nielsen samt undertegnede har til opgave at publicere FOA data. FOA er en kendt forkortelse for mange forskellige ting, men står i vores verden for Den Fælles Offentlige Adressedatabase. FOA indeholder e-post-, postadresse- og kontaktoplysninger på offentlige myndigheder, institutioner og organisationer samt medarbejdere. Du kan se brugergrænsefladen til FOA på borger.dk. Det er dog ikke brugergrænsefladen vi har fokus på, men udstillingen af FOA data på en maskinlæsbar form. Formålet med FOA er at sørge for at oplysningerne om myndigheder og dets medarbejdere er til rådighed for så mange som mulig. Derfor er det en rigtig god ide, at udstille data vha. et API, så så mange som mulig får mulighed for at integrere integrere med FOA og/eller præsentere FOA data i andre sammenhænge end vi går det via borger.dk.

Ultimo 2008 blev version 2.0 af FOA lanceret. Denne version var rimeligt langt fremme i skoene mht. at tilbyde API adgang til FOA’s data: En SOAP snitflade til opdatering og en REST snitflade til publicering af offentlige data. REST snitflade udstiller alle ikke sikkerhedsbelagte data. Sådan skal dét være – lad os dog få udstillet myndighedernes offentlige data. De gode viljer løb dog desværre hurtigt ind i problemer. FOA er lidt af et dukseprojekt, som i bedste stil forsøger at genbruge offentlige data og services. Hvilket jo egentligt er en god genbrugstanke, men genbrug havde i denne sammenhæng - udover de åbenlyse fordele - også mindst en ulempe. FOA anvender nemlig CVR’s adresser, som er betalingsdata, og da ideen bag FOA REST snitflade var, at den skulle være åben og gratis, dukkede følgende problemstilling op: Kunne FOA udstille dele af CVR’s betalingsdata gratis? Problemstillingen blev i marts 2010 afgjort til fordel for dem som ønsker åbne og gratis data.

Så nu var banen kridtet op for os (to Martin’ere og en Finn). Vi var nu klar til at effektuere ministerens beslutning om at publicere VTU data ved at publicere FOA’s offentlige data. FOA REST servicen havde som sagt ligget i dvale siden ultimo 2008 og ikke havde fået det store kvalitetstjek pga. de beskrevne problemer med publicering. Derfor var det første vi gjorde at give FOA REST servicen et tiltrængt serviceeftersyn. Dette eftersyn afslørede en række forbedringsmuligheder: Dokumentationen var svært tilgængelig. Forudsatte nærmest at man kendte FOA’s interne datamodel. Der manglede eksempler på brug af servicen. Nogle småfejl i servicen. En række forhold, som vi gerne ville have styr på inden frigivelsen.

Vi havde derfor følgende ændringsønske til FOA REST servicen: En dokumentation, som rettet mod dem som skal bruge servicen – ikke dem der kender servicens indre, implementationen.

Mange fejl bliver først opdaget når tingene bliver taget i brug, så vi valgte derfor at lave en lille applikation, som anvendte de mest oplagte brugsscenarier af FOA data. Herved kunne vi forhåbentligt finde de mest oplagte fejl, som vi ikke havde opdaget ved serviceeftersynet. Udover at frigive FOA data ønskede vi også at give et eksempel på hvad FOA data kan anvendes til. Mange offentlige ansatte samarbejder på kryds og tværs af organisationer og har hyppigt brug for at kontakte hinanden. Mange borgere og virksomheder har brug for at finde ud af hvordan en given myndighed eller medarbejder kan kontaktes. Og det er jo lige hvad FOA kan. Vi valgte derfor at lave en mobil web applikation rettet mod smartphones, som, når man er på farten, kan anvendes til at få fat på en offentlig medarbejders eller en myndigheds telefonnr, mailadresse eller fysisk adresse, som så kan anvendes direkte af smartphonen til at ringe, maile eller navigere hen til den pågældende medarbejder eller myndigheden.

Vi gik så i gang med at udvikle applikationen og noterede undervejs vores ændringsønsker til FOA REST servicen ned.

Som det kan læses i Rig Web Applikations – kogebogen foretrækker denne type applikationer at anvende JSON formatet, når der skal kommunikeres med den bagvedliggende service. FOA servicen tilbyder i øjeblikket udelukkende XML.

Ændringsønske: JSON/JSONP format.

For at lette udviklingen af den mobile FOA applikation blev der udviklet en serviceproxy, hvis formål det var at konvertere XML data fra FOA servicen til JSON. Da det senere blev opdaget at FOA servicen ikke angav nogen caching directiver i sine respones kunne proxyservicen også anvendes til at etablere dette med henblik på performanceforbedringer.

Ændringsønske: Caching directiver.

Det primære formål med applikationen var at fremsøge personer eller myndigheder, som man havde behov for at kontakte via telefon, email eller besøg. Så jeg gik i gang med at bruge FOA REST API’et til at finde mine to yndlingskollegaer Martin og Martin. Heldigvis har de Martin’er navne der udskiller sig lidt fra de mest hyppige - nemlig Høegh og Ege – så min forventning var at de ville være nemme at finde. Det var de ikke. Jeg fandt overraskende ikke mine to yndlingskollegaer. Efter at have gransket lidt i dokumentationen viste det sig at FOA API’et ikke tillader fritekst søgning inde i et navn. Det giver kun mulighed for søgning i starten af fornavn og efternavn, og da både Høegh og Ege er mellemnavne, som derfor står i slutningen af fornavnet, er det ikke muligt at søge på dem.

Ændringsønske: Fritekstsøgning på navne.

Herefter kom startbilledet til at få følgende udseende:

Startbilledet

Hvis jeg nu havde vidst at Martin hedder Nielsen til efternavn, kunne jeg havde brugt både Martin og Nielsen til søgningen og fået ca. 10 Martin Nielsen’er, som jeg ikke rigtig kan adskille fra hinanden. API’et tilbyder ved søgning på navn kun navnedata og ikke oplysninger om ansættelsessted, telefonnr eller lignende, som ville være bekvemt at præsentere for brugeren til udvælgelse af den rigtige Martin Nielsen samt til præsentation af hyppige anvendte data, som f.eks. telefonnumre. For at få fat i disse relevante eller andre oplysninger personen, skal der foretages flere API kald med dårligere svartider til følge.

Ændringsønske: Søgeresultater leverer – udover navn og link - de mest brugte data om de fundne.

Hyperlinking er, som bekendt, en vigtig del af en REST snitflade, men det er vigtig at hvert link/ressource bibringer væsentlig information. Fra søgelisten fik vi et link til en personrepræsentation, som ikke gav den information, som var ønsket, nemlig personens tilknytning til en organisation – en repræsentation af myndighedspersonen. Der skulle vi følge endnu et link som, bragte os over til den ønskede information.

Det er ikke et optimalt design, som kan løser på flere måder: Flere oplysninger på søgelisten, direkte link fra søgelisten til myndighedspersonen, søgning på myndighedspersoner, osv.

Udover at applikationens performace skulle belastes at et ekstra servicekald var svartiden på hentning af myndighedspersonen urimelig høj: mere end 6 s i gennemsnit.

Ændringsønske: Bedre performance på opslag af myndighedsperson.

i var derfor nød til at gøre brugeren opmærksom på at det tog noget tid at få et svar:

Langsom opslag

Efter at have ventet et stykke tid bliver vi så præsenteret for:

oplysninger om Martin

Hvor vi får mulighed for at ringe til Martin via telefonnummerlinket.

Ring til Martin

Hvis man kigger godt efter kan man se, at Martin er markeret som favorit. Hvis du markerer personer, som favoritter gemmes de lokalt på din smartphone, med mulighed for at tilgå dem uden at have og bruge internetadgang (takket være html 5 Offline og localstorage muligheder). Her er listen over mine favoritter.

Favoritter

Ovenfor blev vi også gjort opmærksom på, at der er problemer med manglende opdateringer. Martins afdeling hedder længere ikke Udviklingsområdet, men Center for digitalisering. Denne ulempe kan ikke håndteres af REST API’et, men må håndteres på anden vis. Til trods for det fejlagtige navn virker linket, så man kan få mere at vide om afdelingen:

Myndighed

Her fra kan man så navigere sig videre til at få vist afdelingen på smartphonens kortapplikation, aktiveret dens telefon med afdelingens telefonnummer, aktiveret dens mailprogram med afdelingens mailadresse og selvfølgelig navigere sig videre via link til tilknyttede organisationer samt medarbejdere.

KortMail

Vi fik frembragt en mobil web applikation til trods for at API’et ikke var optimalt designet til vores brug. Vi kunne have frembragt en bedre applikation hurtigere, hvis API’et havde et bedre design, som opfyldte et typisk behov for anvendelse af FOA data – nemlig at fremfinde personer og myndigheder.

Mange opfatter det at frembringe et API til et web site udelukkende som noget teknisk. Noget der kan frembringes ud fra viden om det bagved liggende system, og uden at fokusere på, at det skal designes med henblik på at opfylde nogle behov for slutbrugere og udviklerne, som skal udvikle applikationerne til slutbrugerne. Det er en fejlagtig opfattelse: At tro at man ud fra data- eller klassemodel kan generere en anvendelig grænseflade – et API. Som ethvert andet artefakt, som skal kunne bruges med fordel, skal det være godt designet. Designet skal tage højde for kravene til det: Funktionaliteten skal være i orden. Det skal være let at anvende. Forståeligt. Når man kender en del af API’et, skal man nemt kunne bruge resten af API’et, da designet selvfølgelig er konsistens. Performance er vigtig. Osv.

Heldigvis har vi mulighed for at gøre noget ved det, da ansvaret for FOA ligger hos os - og det gør vi også. Der er dog liiiiige nogle andre FOA funktionaliter, som har højere prioritet end ændringen af API’et, men så frigiver vi en også en REST snitflade til FOA’s offentlige data.

Det er ikke altid lige let at udstille sine data - det må vi erkende. Jeg tror, at vi med FOA har været en lang række af problemstillingerne igennem, som andre også vil støde på, når de vil udstille deres data: Rettighedsspørgsmål, datakvalitet, udstillingsmåde, designet, performance, prioritering i forhold til at andre opgaver osv. IT- og Telestyrelsen ser i øjeblikket på, hvad vi kan gøre, for at gøre det lettere for andre, at udstille af deres data på en maskinlæsbar form.

Stay tuned.

Finn Jordal /@finnjordal

IT- og Telestyrelsen