Ännu går det inte att få ett nobelpris i API-utveckling (inte ens ett pris till Alfred Nobels ära), men nu finns det i vilket fall ett officiellt Nobelpris-API. Det är ett REST API där man kan hämta information om pristagare och priser. Dessutom så finns samma information tillgänglig som länkad data för den som är intresserad.

Det hela är ett resultat av stöd från VINNOVA som Nobel Media AB fick från den första utlysning för öppna datakällor. REST APIet är utvecklat av mitt företag Dopter, det var jag och Erik Eng som var inblandade i projektet. Den länkade datan är utvecklat av Metasolutions.

Viktiga val på vägen till ett färdigt API

Istället för att gå igenom exakt vilken funktionalitet APIet har (använd API-konsolen så ser ni så tänkte jag gå igenom några av de val vi gjorde under utvecklingen av APIet, lite Behind the Scene alltså….

Användarvillkor

Jag nämner detta först eftersom det är något som alla APIer behöver och som ofta kommer till i panik sist i ett API-projekt. Istället för att vänta till sist så påbörjades arbetet med användarvillkoren samtidigt som utvecklingen av APIet, på så sätt så var APIets användarvillkor redo när det var dags att lansera APIet.

Det är väldigt generösa villkor som gäller för APIet. All data är tillgänglig under Creative Commons Zero licens, med få undantag. Det går alltså att göra nästan vad man vill med datan. Ju mer informationen om Nobelpriset sprids ju bättre är det ju för Nobelpriset.

Felhantering

Personligen är jag allergisk mot APIer med dålig felhantering. Om jag gör något fel när jag använder ett API så vill jag veta det så att jag kan fixa problemet innan jag sätter min kod i produktion. Tyvärr ser jag väldigt ofta APIer som stolt säger att allt är 200 OK även om det helt klart har gått fel, dessutom ger de inte mig som utvecklare någon information om vad det kan vara som har gått fel.

För att undvika dessa problem så lade vi ner mycket jobb på att få felhanteringen så utvecklarvänlig som möjligt. Pröva tex att använda ett felaktigt versionsnummer (api.nobelprize.org/v2/prize.json) eller använda en icke-existerande parameter ( api.nobelprize.org/v1/prize.json?winning=CharlieSheen) så returneras ett felmeddelande som beskriver felet. Dessutom är HTTP statuskoden satt korrekt, bara en sådan sak.

Versionshantering

Ingen vet vad som händer i framtiden, men om det här APIet blir populärt så garanterar jag att det förr eller senare kommer att krävas förändringar av det. För att kunna hantera dessa förändringar så har varje metodanrop “v1” (för “version 1”) i sin URL. Då blir version 2, 3 och 4 enklare att implementera när vi väl kommer så långt. Eller så kanske det aldrig kommer så långt. Oavsett vilket så har vi inte målat in oss i ett hörn.

Att placera versionsnummret direkt i URLen är inte strikt RESTful. Anledningen till att vi trots det valde att ha versionsnummret i URLen och inte i en HTTP header är framförallt att den där är väl synlig. HTTP headers är fantastiskt användbara, men ofta lite hemliga. Genom att ha versionen i URLen så säkerställer vi att ingen missar vilken version som används. Dessutom är det standardsättet att ange version bland alla de stora APIerna som utvecklare har erfarenhet av.

Format

APIet returnerar antingen JSON/JSONP eller CSV. JSON valde vi för att det är det mest populära format bland de utvecklare som använder REST APIer. CSV valde vi för att göra det enkelt att importera den data som APIet returnerar i program som Excel eller Numbers för att där enkelt göra analyser och grafer. På så sätt kan APIet enkelt användas till mer än webb- och mobilapplikationer.

Även vad gäller returformat så valde vi att ha det tydligt synligt i URLen som ett suffix, tex api.nobelprize.org/v1/prize.json?year=2012&category=peace. Detta av samma anledning som vi valde att ha versionen i URLen, alltså synlighet och att det är vad de flesta utvecklare är vana vid.

Plattform

En viktig del av utvecklingen var att komma fram till vilken plattform/språk/ramverk som skulle användas. Kraven var bla att det skulle vara en långsiktig stabil lösning med låg utvecklingskostnad och kostnadseffektivt underhåll. APIet är inte en kortsiktig satsning, så livskostnaden på lösningen var viktig.

De två huvudsakliga lösningar som utvärderades var Windows Azure och att utveckla APIet med LAMP-stacken (alltså i PHP, med Apache och MySQL). Det blev den sistnämnda (med PHP-ramverket CodeIgniter) framförallt för att Nobel Media redan har stor intern kunskap och erfarenhet av LAMP och att det ger dem total kontroll över lösningen. En av de stora fördelarna med Azure är att den hanterar stora variationer i trafik utan problem, men eftersom Nobel Media redan har en väl fungerande CDN-lösning och den data som APIet hanterar är relativt statisk så är trafikmängden inget större problem.

Kom igång med APIet

Är ni intresserade av att använda APIet så är det bara att sätta igång. Det krävs inga nycklar och ingen registrering. Börja med att utforska APIet i API-konsolen (i Dopters egenutvecklade APIHQ), ta en titt på kodexempel och glöm inte att prenummerera på nyhetsbrevet för utvecklare. Vill du ha en snabbintroduktion till APIet så läs gärna mitt inlägg om det på ProgrammableWeb.

Tack Hans Mehlin på Nobel Media och Erik Eng för ett kul projekt. Jag hoppas att ni alla gillar och använder APIet.

Bild: By White House (Pete Souza) / Maison Blanche (Pete Souza) (The Official White House Photostream [1]) [Public domain], via Wikimedia Commons