Webdiensten en apps kunnen met elkaar praten
Je hebt al vaker gelezen over API’s, kort voor Application Program Interface. En het is een term waarover je nog veel meer zal horen, omdat het, volgens een interessant artikel bij ReadWriteWeb, een waren gold rush aan het ontketenen is. Grote bedrijven zoals Intel tonen namelijk belangstelling voor kleinere bedrijven die zich in API’s gespecialiseerd hebben.
Eerst om te beginnen proberen uit te leggen wat het is, zodat je verstaat waarom een API zo belangrijk is. Simpel gezegd is een API een set voorwaarden waaronder de ene applicatie kan praten met een andere. Op je desktop is dat bijvoorbeeld Word waarin je gegevens van Excel, met kolommen en al, kan importeren. Bij webdiensten gaat dat perspectief nog veel verder. Het laat programmeurs toe om toepassingen te ontwikkelen die gebaseerd zijn op webdiensten zoals Twitter of Facebook. Denk bijvoorbeeld aan een dienst zoals Tweetdeck, die gegevens haalt uit Twitter en die in een andere vorm presenteert, combineert. Je post iets in Tweetdeck, en het verschijnt in Twitter. En het is de API van Twitter die dit mogelijk maakt.
Een dienst zoals Twitter heeft zijn API in het begin open gesteld voor iedereen, om die later strenger te maken. Want dat is wat ook meetelt: om zo’n API te mogen gebruiken, moet de ontwikkelaar wel toestemming vragen aan de webdienst, en die kan voorwaarden stellen. Hij heeft de sleutel tot de API in handen, en kan die geven aan wie hij wil, aan elke voorwaarde hij wil – hij kan de deur zelfs volledig open zetten, en zijn API compleet vrij toegankelijk maken.
Maar meestal dus worden er wel regels toegepast voor zo’n API. En dit heeft dan weer geleid tot een nieuwe industrie: de API managers. Zij zorgen voor het proces van het verkrijgen van toestemming voor het gebruik van de API.
De hele API industrie is pas echt explosief gegroeid met de komst van mobiele toepassingen. In plaats van twee aparte versies te maken van software (de ene voor de desktop website, de andere voor de mobiele app), is het veel efficiënter om een API te maken voor de achterliggende dienst, die de data van de gebruikers bevat en de business procedure, en daarop dan desktop en web versies te bouwen van software die praat met dat API.
