API: de digitale stekkerdoos die apps met elkaar laat praten
Elke keer dat je op je telefoon het weer opzoekt, met een app een tafel reserveert of met iDEAL betaalt, gebeurt er iets onzichtbaars: verschillende computerprogramma's wisselen razendsnel gegevens uit. Dat gebeurt via een API, kort voor Application Programming Interface, vrij vertaald een "programmeerkoppelvlak". Het is de afgesproken manier waarop het ene stukje software aan het andere kan vragen: geef mij deze informatie, of voer deze actie voor mij uit.
Een goede analogie is een stopcontact. Je hoeft niet te weten hoe de elektriciteitscentrale werkt om je stofzuiger aan te sluiten; je hebt alleen het stopcontact nodig, met een vaste vorm en vaste spanning. Een API werkt hetzelfde: de maker van een dienst, bijvoorbeeld een kaartendienst of een betaalsysteem, bouwt zo'n "stopcontact" voor programmeurs. Andere ontwikkelaars hoeven niet te weten hoe de dienst vanbinnen werkt, ze hoeven alleen te weten welke "stekker" erin past.
Wat is het precies?
Technisch gezien is een API een verzameling regels en afspraken waarmee software met andere software kan communiceren, zonder dat gebruikers dat zien. De meest voorkomende vorm tegenwoordig is de zogeheten webAPI, die werkt via het internet met hetzelfde protocol als je browser: HTTP.
Zo'n uitwisseling verloopt meestal in vaste stappen. Een app (de "client") stuurt een verzoek naar een server, bijvoorbeeld: "geef me het weer voor Amsterdam". Dat verzoek bevat een adres (een URL), vaak aangevuld met een sleutel (API key) waarmee de aanbieder controleert wie de vraag stelt en hoe vaak. De server verwerkt het verzoek en stuurt een antwoord terug, meestal in een tekstformaat dat zowel mensen als machines kunnen lezen, zoals JSON.
Er bestaan verschillende "stijlen" van API's. REST is al jaren de standaard: simpel, gebaseerd op internetadressen en standaardacties als ophalen, aanmaken, wijzigen en verwijderen. GraphQL, ontwikkeld door Facebook en in 2015 opengesteld, laat de aanvrager preciezer bepalen welke gegevens hij wil, wat dataverkeer kan besparen. Voor razendsnelle verbindingen tussen servers onderling, zoals bij grote clouddiensten, wordt vaak gRPC gebruikt, een protocol van Google.
Belangrijk is dat een API meestal alleen de buitenkant regelt: welke vragen mogelijk zijn en welk antwoord je krijgt. Wat er precies binnenin gebeurt, blijft verborgen. Verandert de aanbieder de interne werking, dan hoeft dat voor de gebruiker van de API niets uit te maken, zolang de afgesproken "stekker" hetzelfde blijft.
Wat wil men ermee bereiken?
Het belangrijkste doel van een API is hergebruik en samenwerking. Zonder API's zou elke ontwikkelaar die bijvoorbeeld een kaart in zijn app wil tonen, zelf een complete kaartendienst moeten bouwen, met satellietbeelden, straatnamen en routeberekeningen. Dankzij een kaarten-API kan hij die functionaliteit "lenen" van een specialist en zich richten op zijn eigen toegevoegde waarde.
Voor bedrijven is een API ook een verdienmodel en een manier om een ecosysteem te bouwen. Door hun dienst via een API open te stellen, moedigen ze andere ontwikkelaars aan om er extra producten bovenop te bouwen, wat de oorspronkelijke dienst waardevoller maakt. Tegelijk vergroot het de macht van de aanbieder: wie de API beheert, bepaalt de voorwaarden, de prijs en soms ook wie er wel of niet gebruik van mag maken.
Op systeemniveau maken API's grote, complexe software behapbaar. Grote bedrijven bouwen hun eigen diensten tegenwoordig vaak als los van elkaar draaiende onderdelen (microservices) die onderling via interne API's praten. Dat maakt het makkelijker om delen van een systeem te vernieuwen zonder alles tegelijk te moeten aanpassen.
Voorbeelden uit de praktijk
Google Maps opende in 2005 zijn kaarten-API, waarna duizenden websites en apps ineens kaarten en routebeschrijvingen konden tonen zonder zelf cartografie te hoeven bouwen. Dit wordt vaak genoemd als een van de eerste grote voorbeelden van hoe een API een compleet nieuw ecosysteem van apps kan aanjagen.
In de financiële sector verplichtte de Europese herziene betaaldienstenrichtlijn PSD2, van kracht sinds 2018, banken om via gestandaardiseerde API's toegang te geven tot rekeninggegevens (met toestemming van de klant). Dat maakte apps als budgetbeheerders en alternatieve betaaldiensten mogelijk, zonder dat die apps zelf een bank hoefden te worden.
Betaaldienst Stripe, opgericht in 2010, bouwde zijn hele bedrijf rond een simpele, goed gedocumenteerde API waarmee ontwikkelaars met een paar regels code betalingen konden verwerken. Het bedrijf wordt vaak als voorbeeld genoemd van hoe een uitstekend ontworpen API zelf een product kan zijn.
Recenter, sinds 2020, bouwde OpenAI zijn GPT-taalmodellen uit tot een API waarmee ontwikkelaars kunstmatige intelligentie in eigen software konden inbouwen, wat de basis legde voor een golf aan AI-toepassingen vanaf 2022 en 2023.
Een tegenvoorbeeld laat zien hoe kwetsbaar dit systeem kan zijn: toen X (voorheen Twitter) in 2023 zijn gratis API afschafte en zeer hoge tarieven invoerde, moesten tal van onderzoekstools, apps van derden en wetenschappelijke projecten die op die data leunden, abrupt stoppen of ingrijpend worden aangepast.
Hoe ver is de techniek?
API's zijn geen opkomende technologie meer, maar een volwassen, wijdverbreid fundament van vrijwel alle moderne software. Het internet zoals we dat nu kennen, met apps die naadloos gegevens uitwisselen, zou zonder API's niet bestaan.
Toch is het veld nog volop in beweging. Er is een duidelijke trend richting betere documentatie en standaardisatie, mede dankzij afspraken als de OpenAPI-specificatie, waarmee API's machineleesbaar beschreven worden zodat tools automatisch documentatie of zelfs testcode kunnen genereren.
Een actueel spanningsveld is beveiliging en controle. API's zijn een populair doelwit voor misbruik: slecht beveiligde of te weinig begrensde API's kunnen leiden tot datalekken, omdat ze rechtstreeks toegang geven tot achterliggende systemen. Beveiligingsonderzoekers wijzen er regelmatig op dat een groeiend deel van datalekken via kwetsbare API's verloopt, wat organisaties dwingt tot strengere authenticatie, versleuteling en limieten op het aantal verzoeken (rate limiting).
Daarnaast speelt een economisch en juridisch vraagstuk: wie bepaalt de voorwaarden van een API, en wat gebeurt er als een aanbieder de toegang plotseling beperkt of duurder maakt, zoals bij X en, in mindere mate, bij Reddit in 2023? Dit laat zien dat API's weliswaar technisch stabiel zijn, maar dat de toegang ertoe een zakelijke keuze blijft van de aanbieder, met soms grote gevolgen voor afhankelijke ontwikkelaars.
Met de opkomst van AI-taalmodellen ontstaat een nieuwe laag: API's die niet alleen data uitwisselen, maar waarbij het "antwoord" zelf door een AI-model wordt gegenereerd. Dat brengt nieuwe vragen met zich mee over kosten, betrouwbaarheid en het controleren van wat zo'n model precies teruggeeft.
Wie werken eraan?
Grote techbedrijven als Google, Microsoft, Amazon en Meta beheren enkele van de meest gebruikte API's ter wereld, van cloudcomputing tot kaarten en sociale netwerken. Specialistische bedrijven zoals Stripe (betalingen) en OpenAI (AI-modellen) hebben hun API juist tot kernproduct gemaakt.
Standaarden komen mede tot stand via organisaties als het World Wide Web Consortium (W3C) en de Internet Engineering Task Force (IETF), die bredere internetprotocollen beheren waarop API's steunen, en de OpenAPI Initiative, die de veelgebruikte OpenAPI-specificatie voor het beschrijven van REST-API's onderhoudt.
Op regelgevend vlak speelt vooral de Europese Unie een grote rol, met de PSD2-richtlijn voor open bankieren en de bredere Digital Markets Act, die grote platforms verplicht om onder bepaalde voorwaarden interoperabiliteit en toegang via API's te bieden aan concurrenten en gebruikers.