Att komma igång

För att komma igång och utveckla behövs ett utvecklingskonto, detta erhålls genom att maila Spotify och snällt be de aktivera detta. Det tog cirka ett dygn för Spotify att aktivera mitt konto, efter detta var det fritt fram att knacka kod! De har publicerat en ganska innehållsrik tutorial vilket gör att man snabbt kommer igång, man har lätt ett fungerande Hello World på några få minuter.

En djupdykning

När det sedan är dags för att faktiskt använda deras API lite mer djupgående blir dock allt betydligt jobbigare. Slår man i deras dokumentation inser man ganska snabbt att den inte alls stämmer bra överens med verkligheten. Detta är visserligen något de nämner i dokumentationen, men det är fortfarande tråkigt att det inte finns några bra referenser att vända sig till. T.ex. saknas all dokumentation om trackPlayer, vilket är en väldigt central del för att kunna kommunicera med klienten.

För att kunna gå vidare i utvecklingen började jag dumpa lite objekt med hjälp av console.log(), vilket mynnade ut i följande metoder på Spotify-objektet (det objekt som getSpotifyApi() returnerar):

• core: function core() { return _getModule(_cache, “core”); }
• desktop: function desktop() { return _getModule(_cache, “desktop”); }
• installer: function installer() { return _getModule(_cache, “installer”); }
• require: function require() { return _require; }
• requireAsync: function requireAsync() { return _requireAsync; }
• social: function social() { return _getModule(_cache, “social”); }
• trackPlayer: function trackPlayer() { return _getModule(_cache, “trackPlayer”); }
• whatsnew: function whatsnew() { return _getModule(_cache, “whatsnew”); }

Om man i sin tur dumpar trackPlayer-objektet fås följande:

• addEventListener: function addEventListener() { [native code] }
• canChangeRepeat: function canChangeRepeat() { [native code] }
• canChangeShuffle: function canChangeShuffle() { [native code] }
• getIsPlaying: function getIsPlaying() { [native code] }
• getNowPlayingTrack: function getNowPlayingTrack() { [native code] }
• getPlaybackControlState: function getPlaybackControlState() { [native code] }
• getPlayingContext: function getPlayingContext() { [native code] }
• getRepeat: function getRepeat() { [native code] }
• getShuffle: function getShuffle() { [native code] }
• getVolume: function getVolume() { [native code] }
• playTrackFromContext: function playTrackFromContext() { [native code] }
• playTrackFromUri: function playTrackFromUri() { [native code] }
• removeEventListener: function removeEventListener() { [native code] }
• seek: function seek() { [native code] }
• setIsPlaying: function setIsPlaying() { [native code] }
• setRepeat: function setRepeat() { [native code] }
• setShuffle: function setShuffle() { [native code] }
• setVolume: function setVolume() { [native code] }
• skipToNextTrack: function skipToNextTrack() { [native code] }
• skipToPreviousTrack: function skipToPreviousTrack() { [native code] }

Detta är helt klart ett ganska omständigt sätt att hitta tillgängliga metoder på, men visst fungerar det. All utdata från console.log() dyker (precis som vanligt) upp i inspektorn.

Lite annat smått och gått som finns att tillgå är all källkod som Spotify skickar med i beta-versionen, där finns bland annat ett antal väldigt användbara exempel. Använder man Mac OS X återfinns allt detta i /Applications/Spotify.app/Contents/Resources/cef_views/. Här finns bland annat exempel på hur man kan implementera tabbar och andra trevliga UI-element.

Ett kort exempel

Under tiden jag testade på API:et tog jag fram en (extremt) liten applikation som startar musiken även om någon försöker använda samma Spotify-konto. T.ex. är det detta som inträffar om man försöker använda Spotify på datorn samtidigt som på telefonen. Varningsmeddelandet “Spotify has been paused because your account is used somewhere else” dyker fortfarande upp, men ingen störningen i musiken hörs.

Detta lilla exempel återfinns här och utgör hela 56 rader kod. Trots att det är ett väldigt litet exempel säger det endel om hur kraftfullt API:et faktiskt är.

Slutsats

Till sist måste jag säga att det är riktigt trevligt att arbeta med Spotifys nya API. De har tagit fram ett kraftfullt API tillsammans med en trevlig utevcklingsmiljö och en bra debugger. Det kommer säkerligen komma en hel drös med trevliga applikationer som kommer göra musikupplevelsen på Spotify än bättre. Det jag saknar är en bra referens till alla metoder och objekt, jag hoppas innerligt att Spotify fixar till detta så småningom.

Systemet API – hämta endast den data du vill ha

Med Systemet API så kan man hämta endast de produkter man är intresserad av, tex endast whisky eller endast vita viner som kostar max 80 kr. Man kan också hämta ut detaljerad information om en enskild produkt. Det är samma data som är tillgänglig direkt via Systembolagets filer men organiserad på ett mer lättanvändbart sätt.

Vill man hämta ut alla produkter som kostar max 10 kr (fint ska det va!), med en max volym på 33cl och sortera på billigast pris så ser anropet ut så här:

http://systemetapi.se/product.json?max_price=10&max_volume=0.33&order_by=price&order=ASC

Tillbaka får man JSON, tex:

    {
        article_id: "338516",
        name: "San Miguel",
        name_2: "0,0%",
        price: "9",
        volume: "0.25",
        price_per_liter: "36",
        type: "Alkoholfritt, Öl",
        packaging: "",
        closure: "",
        origin: "Spanien",
        origin_country: "Spanien",
        producer: "San Miguel",
        year: "0",
        alcohol: "0",
        alcohol_percent: "0%",
        apk: "0",
        ecological: "0",
        koscher: "0"
    }

Från exporterade filer till användbart API

APIet är skrivet av Karl Roos på Vimea med hjälp av PHP, MySQL och hans egenutvecklade ramverk Solidocs. Det började med att en av Karls kollegor ville bygga en APK-app (milliliter alkohol per krona) och behövde en backend, resultatet är ett API som vi alla kan använda. I framtiden så kommer han att lägga till butiksinformation, förbättra filtrerings och sorteringsalternativen samt att lägga till historik på prisförändringar.

Själv tycker jag att det är bra jobbat av Karl att ta intressant data, organisera den och göra den tillgänglig på ett mer användbart sätt. Det vinner alla på, inklusive Systembolaget som får ett bra API utan att behöva investera tid och resurser på det. Förhoppningvis så kommer inte Systembolaget att reagera negativt på Karls jobb. Han har försökt får ett svar från dem om man får utveckla ett API ovanpå deras filer, men han har ännu inte fått något konkret svar.

Cash Rules Everything Around Me

Vi börjar med ett praktiskt API för att värma upp, nämligen Open Exchange Rates som ger tillgång till växelkurser mellan nästan alla världens valutor. Det finns också ett bra javascriptbibliotek, money.js om man vill använda växelkurserna direkt i Javascript.

Ett annat pengarelaterat API är Handelsbankens inofficiella API som Björn Sållarp har dokumenterat genom att sniffa trafiken till och från Handelsbankens iPhoneapp. Med APIet kan man lista konton, lista kreditkort, föra över pengar mellan konton etc.

När man har all information om sitt bankkonto och om växelkurser så vill man ju visa dem i fina diagram, och där är Google Charts API mycket användbart. Med det kan man göra snygga pajdiagram, stapeldiagram och alla andra typer av diagram bara genom lite javascript.

Med APIer kommer man åt allt

Google har väldigt många APIer och de har alla en massa metoder och parametrar. Som tur är så finns Google APIs Discovery Service vilket är ett API för att få reda på information om ett 20-tal av Googles APIer. Väldigt meta.

Räcker inte alla Googles APIer så kan man bygga ett eget mot vilken webbsida som helst med Diffbot. De använder “visuella algoritmer” för att analysera en webbsida och automatiskt returnera den information som är mest intressant. Ett perfekt sätt att bygga RSS-feeds för sidor som inte har det eller att få veta när en webbsida har uppdaterats.

Behöver man information från email istället så kan man använda Context.io som ger ett API mot ett mailkonto. Perfekt för att ta fram alla konversationer med en given kontakt i ett CRM-system eller att komma åt bifogade filer.

Ibland har man bara en emailadress, men man vill veta mycket mer om personen bakom emailadressen. Då kan man använda Fullcontact APIet där man skickar in en emailadress och får tillbaka information som namn, ålder, kön, profilbilder etc som har samlats ihop från olika tjänster på nätet. Perfekt för att få mer information om sina kunder.

APIer för designers

Att koppla en emailadress till ett namn kan vara användbart, men ibland behöver man 100-tals namn för tester eller för att populera designmockups med realistisk data. Med NamnAPI så kan man generera svenska mans- och kvinnonamn slumpvis. Enkelt och användbart.

Behöver man längre texter för sina mockups så är Loripsum APIet ett bra val. Med det APIet så kan man generera “Lorem ispum…” texter i olika längd och formaterat på alla möjliga olika sätt. Behöver man dessutom bilder för sina mockups så kan man få det via Flickholdr som returnerar bilder från Flickr. Ange bara vilken tag bilden ska ha, tex “sunrise” eller “stockholm”, och vilken storlek den ska ha och tillbaka får man en bild. Aldrig mer behöver mockups ha gråa tråkiga exempelbilder.

Storebror vet vem du är

Med Flickholdr kan man få fram slumpvisa bilder, men tänk om du har en bild på en person och vill veta vem det är. Då är APIet från Face.com vad du letar efter. Börja med att ladda upp en stor mängd personbilder med tillhörande namn, tex alla dina Facebookvänner. Skicka sedan upp en ny bild på en person och du får tillbaka ett namn. Både lite skrämmande och otroligt coolt samtidigt.

När du väl har namnet på personen så kan du hitta hans telefonnummer via APIet från 118100. Skicka in ett namn och få tillbaka adress och telefonnummer, eller skicka in ett nummer och få tillbaka ett namn.

Telefontjänster

När du väl har en persons telefonnummer så kan du skicka honom ett SMS via 46elks. Med deras API kan du också ta emot SMS och koppla röstsamtal. Har du ett telefonnummer så kan man ta reda på vilken operatör (Telenor, 3, Telia etc) som numret tillhör via Post- och Telestyrelsens API. PTS fick många frågor om vilken operatör som hade hand om ett visst nummer, men genom att publicera ett API så kan de spara pengar på support.

Från punkt A till punkt B

Ibland vill man inte ringa eller SMS folk, utan faktiskt göra något så gammaldags som att skicka ett paket. Det kan ju kosta en hel del pengar och det finns många tjänster att välja bland. Fraktjakts API hjälper till att hitta det billigaste alternativet och där kan man dessutom beställa transporttjänsterna direkt via APIet.

Vill man flytta sig själv istället för ett paket så kan man använda ytterligare ett inofficiellt API. Precis som Handelsbankes så har SJ en iPhoneapp och precis som för Handelsbanken så blev SJs app-API dokumenterat och publicerat. Tack vare Erik Pettersson så finns det nu bra dokumentation för SJs API för tidtabeller, stationer och annan tåginformation.

Är” SOAP” en svordom?

Tänker man SJ tänker man lätt på svordomar, och är man som jag så tänker man direkt på ett svordoms-API. I Googles What Do You Love tjänst så vill de undvika fula ord, och de skapade därmed ett API där man kan skicka in ett engelskt ord och få tillbaka True eller False om det är en svordom eller inte. Google dokumenterade inte detta API, men det går inte att gömma någonting så det finns bra dokumentation i alla fall.

Googles svordoms-API funkar som sagt bara för engelska ord och jag har inte hittat någon svensk motsvarighet, men Libris har ett väldigt användbart svenskt stavnings-API. Stavninsförslagen baseras på dels innehållet i bibliotekssystemet Libris och dels på sökningar som användare har gjort i systemet.

Offentlig data + UFOs?

Informationen i Libris är ju nästan offentlig information och det finns många andra exempel på hur offentlig data finns tillgänglig via API (jag vet att denna övergång är lite långsökt, försök att förlåta mig). Ett mycket bra exempel är Openaid som är ett samarbete mellan SIDA och UD och ger tillgång till biståndsdata. Vill du veta vilka bevattningsprojekt i Kenya som Sverige gav bistånd till 1997 så är det bara att använda Openaids API och söka upp informationen.

Det skulle vara mycket intressant om någon kunde samköra Openaid APIet med UFO Sightings APIet som gör det möjligt att söka bland rapporterade UFOs välden runt. Finns det något sammanhang mellan vad Sverige har gett bistånd till och var det syns flygande tefat? Har starka misstankar på att det finns en konspiration dold här någonstans!

Vill du att jag ska komma och presentera möjligheterna med APIer, affärsstrategier eller hur man kommer igång? Skicka ett mail till andreas@dopter.se eller ring mig på 0709-780794.

Hela er affärside bygger på ert API , vilket är rätt ovanligt för svenska företag. Hur kommer det sig att ni gick den vägen?

Till största del har vi valt att lägga fokus på vårt API när det gäller att tillängliggöra vår textanalysteknik. Vi har även utvecklat ett par produkter som används, men med tiden har vi fokuserat mer på vårt API. Eftersom tekniken har så många tillämpningsområden så känns det i nuläget fel att låsa sig till en produkt eller bransch. Nu kan vi vara väldigt flexibla och kombinera olika tekniker för olika syften. Dessutom använder vi själva vårt API till alla produkter och prototyper vi bygger.

Ni har väldigt bra API dokumentation och bibliotek på flera språk, hur kommer det sig att ni har satsat så mycket på det?

Som utvecklare så vet vi hur det är när man skall prova ett nytt API. Ofta så är det en ofärdig dokumentation, bibliotek som inte underhålls och svårt att förstå hur det är tänkt att man skall använda APIet. Detta beror säkert i många fall på att APIet är en biprodukt av en större tjänst (Twitter, Facebook, m.fl.). Eftersom vårt API är vårt ansikte utåt så är det också viktigt att det håller hög standard, både när det gäller vad tekniken levererar och hur det är att arbeta med.

Vilka begränsningar finns på APIet?

Beträffande antal anrop, språk och andra begränsningar som kan förekomma diskuteras dessa alltid med våra kunder och prissättningen görs därefter. För utvecklare som vill testa vårt API eller använda det för non-commercial så ligger gränsen för närvarande på 2000 anrop per månad. Det finns även begränsning för hur många Collections och Groups man kan skapa. Mer information om detta kommer läggas ut på vår hemsida.

Hur har ni byggt er tekniska plattform så att ni kan klara av både hög trafik och hög concurrancy?

Idag har det vuxit till ett rätt stort system med flera olika komponenter som sköter sin lilla bit i pusslet. Rent hostingmässigt använder vi oss till största delen av molntjänster för att snabbt kunna skala upp antalet maskiner när det behövs. Vi delar upp infrastrukturen i fyra delar; Web-API, databaser, cache och beräkningsmaskiner varav alla skalar oberoende av varandra, sen limmar vi ihop de olika delarna så de kan kommunicera med varandra på ett bra sätt.

Vilket var största utmaningen med att bygga ert API?

Om man bortser från hur svårt det är att göra riktigt bra textanalyser och fokuserar helt på vårt Web-API så är det inte helt lätt att få ihop allt för att kunna skala horisontellt. Exempelvis att kunna stänga av och på maskiner utan att påverka existerande API-sessioner är något som vi arbetat mycket med och som vi kommer fortsätta utveckla. Sedan är ju självklart hela delen med dokumentationen en riktig utmaning, bara att namnge metoderna och parametrarna satt vi flera veckor med. Till skillnad mot den första versionen av APIet så var vi mycket noga med att det skulle vara förståeligt och att varje metod och parameter representerar det man tror att den gör. Kodbiblioteken har också byggts om 2-3 gånger innan vi blev helt nöjda med dem.

Vad har ni lärt er medans ni har byggt ert API?

• Att försöka hålla APIet så stateless som möjligt. Som i vårt fall använda oss av egna sessions som vi sparar Memcached istället för att använda webserverns session id. På det sättet kan man enkelt skala upp med fler maskiner utan att en användare är bunden till en viss maskin.
• Utgå från att användaren har väldigt lite kunskap inom det specifika området. Det är väldigt lätt att man blandar in internt språkbruk i både dokumentation och namngivning i API:et. Stanna upp och reflektera kring om det är någon annan som egentligen förstår vad du försöker säga. Ännu bättre är att testa med användare.
• Det skall vara tillräckligt lätt att komma igång och använda utan att förlora för mycket flexibilitet. Detta har vi försökt göra genom att sätta sunda defaultvärden på så många parametrar som möjligt.
• Att i dokumentationen inte enbart förklara hur någonting används (x metod tar y parametrar) utan att även komplettera med hur det är tänkt att användas, och framförallt visa upp kod hur man gör det.

Har du exempel på vad era kunder använder ert API till?

• Vanligt förekommande är att man ersätter sin manuella taggning av texter till att uteslutande använda automatisk taggning istället. På det sättet sparar man mycket tid, stärker sin SEO och kan bygga automatiska temasidor.
• Att hitta och presentera relaterade och liknande artiklar från arkivet eller från en sida som är inom samma koncern eller inom samma område. Detta ger bra internlänkning och ökar antalet sidvisningar.
• Att analysera stora textflöden och filtrera texter till användare baserat på deras personliga intressen. Exempelvis att användare som är intresserade av ett visst intresseområde får rekommendationer av bra texter som matchar deras profil.
• Optimera annonsplacering baserat på texters kontextuella betydelse.
• Analysera om texter och kommentarer är positivt eller negativt skrivna för exempelvis en produkt eller ett företag.

Tack Fredrik för all intressant info och tack Saplo för ett riktigt bra API!

När jag var i Stockholm för några veckor sedan så tog jag en fika med Pejman, en av grundarna, och pratade APIer och entreprenörskap. Det är riktigt kul att se en svensk startup med så mycket driv som 46elks har, det extra kul att se att deras affärside är ett API och ett riktigt bra API dessutom.

Telefonnummer

För att kunna använda SMS och röstsamtals APIerna så måste man ha ett speciellt telefonnummer. Detta nummer skapas via ett API anrop, närmare bestämt en POST till https.//api.46elks.com/a1/Numbers . När man väl har ett nummer så är det detta nummer som man kan ta emot SMS på, skicka SMS från eller hantera röstsamtal. För varje nummer så kan man registrera callback metoder som används för att hantera SMS respektive röstsamtal.

SMS API

När ett SMS skickas till ett 46elks nummer så kallar nummrets SMS callback metod med en POST. Detta anrop innehåller information om vilket nummer SMSet är från och texten i SMSet. Sedan är det upp till dig som API användare att implementera denna callback metod och hantera den data som skickas i SMSet. Via APIet så kan man svara på ett inkommande SMS eller skicka ett SMS till vilket mobilnummer som helst.

Röstsamtals API

Om någon ringer ett 46elks nummer så kallas den registrerade callback metoden med en POST som innehåller information om vilket nummer det är som ringer. Baserat på vem det är som ringer så kan man sedan koppla vidare samtalet till något annat nummer eller lägga på. Man kan också ange villkor som att man först kopplar vidare till ett telefonnummer, men om det är upptaget så kopplar man vidare till ett annat.

Prissättning

Just nu är APIet i alpha, så det kostar absolut ingenting att använda det. I framtiden så kommer det att finnas en fast månadskostnad för varje 46elks nummer på runt hundralappen, samt en mindre kostnad på några öre per SMS. De kommer snart ut med officiell prissättningen, men det jag har hört låter väldigt konkurrenskraftigt.

Sammanfattning

46elks API har oändlig potential. Varför inte bygga en version av Google Voice för den svenska marknaden? Varför inte köra användarverifiering via SMS istället för via email? Varför inte ha ett 46elks nummer som företagets officiella nummer och sedan automatiskt koppla det vidare till vem det nu är som är on-call just nu?

Om prissättningen blir rätt så tror jag att 46elks kan bli en riktig framgångssaga. De tillhandahåller den infrastruktur som många entreprenörer behöver för att kunna förverkliga sina ideer. Det enda jag saknar från 46elks API idag är ett sätt att ta betalt av dem som skickar mig SMS, en tjänst som tex Telenor tillhandahåller.

Är det någon som har använt 46elks API eller några liknande APIer? Vad har ni gjort med dem och vad är era erfarenheter?

Två API nivåer

När man registerar sig som användare av Eniros API så får man Basic level, dvs begränsad tillgång till data samt max 10.000 anrop/månad. Är man partner med Eniro får man istället Full level access, dvs obegränsat med anrop och mer data via APIet. Det är inte helt självklart vilka villkor man måste uppnå för att kunna bli partner, utan man ska kontakta Eniros partner team och ta en diskussion med dem.

Enligt dokumentationen så är den stora skillnaden mellan Full och Basic att man med Basic inte har tillgång till viktig information som tex företagsnamn, position (long/lat). Enligt mina tester så har man dock tillgång till det mesta även med Basic, även om det varierar mycket från metod till metod. Kanske kommer företagsnamn etc att försvinna från Basic snart, så jag skulle inte bygga en app som använder sådan info utan att först bli Full användare eller i alla fall kolla med Eniro först.

Sök efter företag

Man kan söka efter företag med angivna sökord och ett geografiskt område, tex för webbyråer i Helsingborg. Konstigt nog finns det två metoder för att göra denna sökning, antingen via Company Search eller via Company mobile search. Själv har jag inte lyckats hitta någon skillnad på dessa två metoder, men jag antar att det finns någon subtil skillnad gömd någonstans.

Sökningen efter webbyråer i Helsingborg ser ut så här med Company Search:

&search_word=webbyr%C3%A5&profile=&version=1.0.1&key=


API profil och API nyckel skapar man gratis på api.eniro.com. Land måste alltid anges som “se” om man vill söka i Sverige. Alternativen är “krak” för att söka i Danmark på Krak.dk och “no” för att söka i Norge på Gulesider.

Ett annat sätt att leta efter företag är med Company proximity search där man söker inom X antal meter från en given longitud och latitud.

Sök efter personer

Uppdatering (2011-10-17): Eniro verkar ha tagit bort sitt person API, men jag har inte lyckats få fram varför.

Precis som för företag så söker man efter personer i ett visst geografiskt område och med angivna sökord med Person search. Följande anrop returnerar en lista på advokater i Stockholm:

http://api.eniro.com/ps/search/basic?profile=&version=1.0.0
&key=&country= se&search_word=advokat&geo_area=stockholm


Man kan också söka efter personer inom ett visst geografiskt område baserat på longitud och latitud med Person Proximity Search.

Sammanfattning

Jag tycker om att Eniros API ger tillgång till riktigt mycket data på ett snyggt och lättanvänt sätt. Dokumentationen av APIet är OK och det är snabbt att få en API nyckel och sätta igång att testa. Tyvärr så begränsas APIet en hel del genom sina licensvillkor och då tänker jag främst på att data man får från APIet inte får lagras på något sätt, endast användas on demand. Det är alltså mot villkoren att cacha data eller mellanlagra i en databas. Detta är inte ett ovanlig villkor i API sammanhang, men det sänker värdet på APIet en hel del. Det är förståeligt att Eniro inte vill att någon bygger upp en speglad version av eniro.se, men att inte tillåta någon sorts mellanlagring är att gå lite långt. Begränsa mellanlagringen till 24 timmar så att det går att cacha data ordentligt och få lite prestanda i de applikationer som bygger på APIet.

Det är ett mycket bra och smart initiativ av Eniro att släppa detta API och jag hoppas det blir populärt så att andra svenska företag får upp ögonen för de möjligheter som ett API ger.

Följ @EniroAPI på Twitter för nyheter om detta API och följ mig, @andreaskrohn för att få API nyheter i allmänhet.

Få tillgång till APIet

För att börja testa APIet så måste man aktivera Google+ APIet i Google API Console. Eftersom APIet nu endast är till för att testa och ge Google feedback så får man nu bara 1000 anrop/dag.

Än så länge så har man bara tillgång till att läsa publik data. Antingen så använder man en API nyckel som man får via Google API Console eller så loggar man in via Oauth 2.0. Själva APIet är REST och returnerar JSON.

Metoder

För att hämta publik information om en användare så kallar man https://www.googleapis.com/plus/v1/people/<ANVÄNDARID>?key=. Är man inloggad via OAuth så byt ut API nyckeln (“key” parametern) mot “access_token” istället.

Förutom publik information om en användare så kan man också få tag på en lista av en användares publika aktiviteter via https://www.googleapis.com/plus/v1/people/<ANVÄNDARID>/activities/public. För mer info om en given aktivitet så kallar man https://www.googleapis.com/plus/v1/activities/

Mer om dessa metoder finns i Google+ API dokumentationen

Det finns klientbibliotek för PHP, Ruby, Python, Objective-C. NET och andra språk.

Så nu finns det inga ursäkter, låt hackandet börja!

APIer

Det finns som sagt 6 APIer som ingår i själva Trafiklab, det är alltså APIer som är tillgängliga via api.trafiklab.se, där dokumentationen finns på trafiklab.se och där man får API nycklar direkt från sajten. Dessa sex APIer är:

• SL Realtidsinfo – realtidsinformation om SLs bussar, tunnelbaner, tåg etc. När är nästa avgång från en given station till exempel.
• SL Trafikläget – övergripande status på SLs trafik
• SL Störningsinformation – ta reda på existerande och planerade störningar i SLs trafik
• SL Reseplanerare – planera din resa från punkt A till punkt B
• Samtrafiken Sök resa – ytterligare ett reseplanerar API, men detta API täcker hela landet och inte bara Stockholmsområdet
• Samtrafiken Stolptidtabeller – hitta avgångar från olika hållplatser över hela Sverige

Det jag främst har gjort i projektet är att ta existerande SL och Samtrafiken APIer och förenkla för utvecklare att använda dem. I det ingår bla att alla APIer ska vara tillgängliga via REST, att de alla ska returnera både XML och JSON och att de alla ska ha liknande struktur på URLer och dokumentation. Mycket av dessa förenklingar och förändringar av existerande APIer har gjorts via Apigee som bla gör det möjligt att i runtime göra om ett REST anrop till SOAP, så att inget i själva backend behöver förändras.

Även om det finns mycket jobb kvar med Trafiklab innan allt är perfekt (sajten är ju fortfarande i beta) så är det ett mycket stort steg i rätt riktning. Målet är att göra svenska reserelaterade APIer så enkla som möjligt att använda så att så många utvecklare som möjligt kan använda dem. Gå gärna in och pröva Trafiklab och ge oss feedback (gärna via trafiklab.se och inte direkt till mig) så vi kan göra sajten ännu bättre.

TravelHack

Om du är intresserad av APIer och resande så är TravelHack 8-9 oktover i Göteborg perfekt för dig. Det är ett event där man under 2 dagar hackar med rese-APIer och har chansen att vinna finfina priser. Själv hoppas jag kunna vara där och fungera som hjälpande resurs för alla de tävlande lagen. Anmäl dig redan idag!

Den som väntar på något gott väntar alltid för länge

Google har lovat att det kommer ett API för Google+, men inte förrän om några veckor eller flera månader, beroende på vem man lyssnar på. Undantaget är om du är en “Trusted Tester”, då kan du börja använda APIet redan om några dagar. Tyvärr är jag inte en Trusted Tester, tydligen måste man vara finansierad av Googles egen VC fond för att vara det. Synd att Google+ API dröjer så, jag saknar verkligen G+ integration i många appar och jag tror att ett API skulle kunna ge G+ en ordentlig push framåt.

Även om det inte finns ett officiellt Google+ API så hindrar det inte att man kan skapa ett eget API. Emailföretaget Powerinboox har gjort just detta och på så sätt integrerat Google+ i sin emaillösning. Det visar att man inte kan kämpa emot utvecklingen, snart kommer all info att ha ett API (låt mig drömma om det i alla fall)!

Viadeo lanserar API för att konkurrera med LinkedIn

Viadeo är ett socialt nätverk som liknar LinkedIn, dvs fokus är på jobb och karriär. De har 35 miljoner användar världen över, mest i Indien och Kina. I veckan så lanserade Viadeo sitt API i USA. För att de ska ha en chans på den stora amerikanska marknaden så måste de ha ett API, annars kommer alla utvecklare som gör rekryteringsappar etc att använda LinkedIns API istället. Frågan är om det inte är för sent för Viadeo i vilket fall, LinkedIn har kanske redan nått kritisk massa.

Smått och gott från Google

Google API Client Library för PHP finns nu tillgänglig i betaversion. Biblioteket täcker URL shortener APIet, Tasks API, Latitude API och några till. Många av Googles mest intressanta APIer saknas, men de ska snart också få PHP stöd.

Blogger har nu fått ett JSON API. Fokus är på att göra det enklare att använda Blogger APIet ifrån javascript.

3 skäl att du behöver ett API

Som avslutning så tipsar jag om 3 skäl att du behöver ett API som jag har publicerat på Dopter.se. Hoppas minst 1 av de 3 skälen stämmer in på just din situation så att vi kan få många fler svenska APIer.

Facebook Graph API Explorer
Facebook har ett riktigt bra API och nu är det lättare än någonsin att experimentera med det genom deras nya API Explorer. I ett enkelt web interface så kan man testa alla Graph API metoder, se hur anropen och svaren se ut. Om ett svar på ett API anrop innehåller id på något annat objekt så kan man helt enkelt klicka på det id:t för att komma vidare till det relevanta API anropet för att få all data om objektet. Det är bra sätt att borra sig djupare ner i Facebooks API. Oavsett om ni använder FBs API eller inte så tycker jag att ni ska ta några minuter för att experimentera med API Explorern och upptäcka möjligheterna med APIet.

LinkedIn Groups API
LinkedIn har nu utökat sitt API med stöd för Groups, så att det via APIet går att hantera diskussionerna i en grupp, hantera gruppmedlemskap etc.

Samtidigt så stängde LinkedIn av API access till flera stora användar, bla Monsters rekryterings app Beknown. Detta för att de har brutit mot LinkedIns Terms of Service och har försökt tjäna pengar på LinkedIns API. Det handlar mest om existerande eller potentiella konkurrenter till LinkedIn som har blivit avstängda.

Google+ API kommer, men inte riktigt än
Om någon har missat det så har Google lanserat Google+, ett snyggt försök att samla in mer datapunkter för att förbättra sin sökning genom att skapa ett socialt nätverk. Ännu finns inget API till Google+, men Google har redan lovat att det kommer. Vic Gundotra, högsta hönset på Google vad gäller social media, har sagt att det är “inconceivable I would build something without a platform“. Vackra ord för oss som gillar APIer.