Saplo är ett svenskt företag som erbjuder tjänster för att analysera texter. De kan identifiera och automatiskt tagga tex personer, organisationer och platser i en text, eller räkna ut vilka texter som relaterar till andra texter. Dessutom kan de kategorisera texter och räkna ut om en text skribent är positivt eller negativt inställd till ett ämne. Allt detta (och lite till) finns tillgängligt via deras Text Analysis API. De har fått bra recensioner av bla Programmableweb och är ett bra exempel på hur man kan bygga en affärsverksamhet där den enda produkten är ett API. Jag har gjort en emailintervju med Fredrik Hörte på Saplo om just detta och om vad de har lärt sig om att bygga APIer under resans gång….

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!