Idag befinner jag mig på knytkonferensen SSMX i Stockholm. Konferensen håller på hela dagen på Hilton Slussen i Stockholm. Första passet jag valde att gå på handlade om API:er och hölls av Martin Comstedt som är produktägare för API:er hos Eniro. För att beskriva hur ett API fungerar gjorde han liknelsen med att ha ett förråd med data.
– Om folk utifrån ska hämta saker vill vi inte att hela världen ska gå in i vårt förråd och hämta saker. Ett API är som en dörrvakt mot omvärlden som står vid förrådet och delar ut data på ett tydligt sätt, säger Martin Comstedt.
Fördelen med API:er är att de är hyfsat plattformsoberoende. API:et är ett gränssnitt mellan saker och så länge båda sidor pratar med samma standard fungerar det oavsett plattform. API:et pratar ren http och kan användas både internet och externt för utbyte av data.
– Det enda ett API gör är att som dörrvakt släppa in någon så länge den uppger rätt information (credentials). Så länge du ställer rätt fråga kommer API:et att dela ut sin data, säger Martin Comstedt.
Det kan bli ganska mycket anrop med många variabler när man börjar använda API:er, därför behövs en bra struktur för hur man gör anropen så att man håller dörrvakten glad.
– Tidiga API:er gav ganska pratiga svar. Det som är vanligast nu är att man får tillbaka ett svar i XML eller JSON. Världen börjar mer och mer gå åt JSON. XML är ett markupspråk som är släkt med HTML och bygger på hakar och attribut. Det har på senare år börjat betraktat som pratigt och att det tar onödigt mycket plats. JSON bygger på javascript, precis som AJAX, säger Martin Comstedt.
Varför har man ett API? Första svaret är för att det är lite trendigt enligt Martin. Internet har alltid handlat om ”sharing is caring”. Men på senare tid har öppna data från myndigheter hamnat på tapeten. PSI-direktivet från EU handlar om att myndighetsverksamhet som ger ifrån sig några större datamängder ska vara tillgängligt för allmänheten.
– Det var lite oväntat men ganska bra grej av EU. Det ledde till att helt plötsligt har massa myndigheter börjar skapa API:er.
API:er skapar också trafik, vilket kan vara en orsak till att ha ett API för ett företag. Det handlar också om branding och att framstå som generös med sin data. Enligt Martin Comstedt kan ett API också handla om att skapa världsherravälde, vilket Facebook delvis gör när de skapat möjlighet för andra tjänster att använda Facebooks medlemsinloggning som identifikation.
– Google och Twitter gör samma sak. Aldrig mer behöver man skriva en login-funktion. Folk kan använda konton som de har någon annanstans. Det är ganska smutt.
På sajten Programmable Web listas API:er som är bra att ha. I Sverige samlar Andreas Krohn API-databaser på Mashup.se och han har listat över 200 stycken svenska källor. Att kombinera datakällor brukar kallas att göra en mashup. Att till exempel ta data personlig från musiktjänsten Last.fm och kombinera det med Spotifys musikdatabas för att skapa individanpassade spellistor är ett exempel på en mashup.
– Om man har ett internt API och vill göra ett externt API så kan det vara bra att veta hur man vill att ens data ska använda. Det finns en del API:er som är fria att använda så länge det du själv gör är gratis och fritt, men som inte får användas för kommersiella syften, säger Martin Comstedt.
Framtiden för Eniros API:er handlar dels om vad de får dela med sig av i förhållande till de dataleverantörer de har och dels den företagsmässiga aspekten. De kommer att fortsätta utveckla API:erna med fokus på att göra bra data tillgänglig.
5 kommentarer
Bra att du förklarar vad en betydelse av förkortningen ”API” är.
Men, det som jag skulle vilja se i ”del 2” är att du talar om vilka s.k. API:er som är bra, vilka som är usla och framför allt vad API:er var en gång i tiden.
Dvs, jag ser en enorm skillnad mellan:
1. Ett tex REST-baserat gränssnitt som det finns dokumentation på som går att använda för att komma åt en typ av information på en ”webbplats”.
2. Ett standardiserat protokoll över HTTP som används för tex att hantera viss typ av data (som därmed har ett standardiserat format). Oavsett vem som kör tjänsten.
3. Ett standardiserat bibliotek som tillför metoder som kan användas när man skapar program och tjänster.
Tyvärr är det alldeles för många som gör (1) och tycker de är klara, och jätteduktiga. Suck. Det är därför vi har så många olika journalsystem vid sjukhusen, så många e-fakture-grunkor och liknande.
Nej, avgör vilka API:er som är riktiga standarder, publicera dem och kasta resten i papperskorgen.
Bra synpunkter Patrik. Vill dock betona att det här är ett referat av en föreläsning av Martin Comstedt på SSMX, inte en researchad artikel så att säga.
Bra sammanfattning av APIer av Martin och bra blogginlägg av dig, tack för det. Kan tipsa om nordicapis.com i mars och september, ett oar konferenser om just APIer för er som vill gräva på djupet.
[…] Fredrik ”Bisonblog” Wass: API for dummies: […]
[…] Programming Interface, og kort fortalt kan man si at vårt API lar ditt nettsted bruke våre data. Bisonblog skriver om Martins API-session, og vi anbefaler en kikk på det innlegget. En liten «API for […]