API (Application Programming Interface (programmeerinterface))

Een API is een gepubliceerd contract waarmee een systeem data of acties kan opvragen bij een ander, met aangekondigde operaties, inputs en outputs.

Wat is een API?

Een API is een contract tussen twee systemen. Het ene publiceert een lijst met operaties, geeft aan wat elk ervan aanvaardt en wat het teruggeeft, en verbindt zich ertoe dat gedrag stabiel te houden. Het andere roept die operaties aan zonder te weten hoe ze geïmplementeerd zijn, en zonder toegang tot de code of de databank.

Het woord beschrijft de afspraak, niet de technologie. HTTP-requests die JSON teruggeven zijn vandaag de gangbare vorm, maar hetzelfde idee dekt een querytaal, een message queue of een bibliotheekaanroep. Wat een API tot een API maakt, is dat het gedrag aangekondigd en stabiel is, niet het kanaal waarlangs het loopt.

Die invalshoek is belangrijk omdat ze de echte vragen uit de technische kolom haalt. Weten of een systeem een API heeft, is bijna nooit interessant. Wat ze beschikbaar stelt, wat ze achterhoudt, wat ze kost en hoelang ze ongewijzigd blijft, bepaalt of een integratie een project van twee weken is of een permanente last.

Waarom API’s belangrijk zijn

Voor een bedrijf dat software koopt of bouwt, volgen daar rechtstreeks vier gevolgen uit.

• Een API bepaalt of u kunt vertrekken. Een product waarvan de data alleen via een manuele export toegankelijk zijn, zal duur zijn om te vervangen. De aanwezigheid van een gedocumenteerde API, en de omvang van wat ze beschikbaar stelt, zijn de praktische maatstaf voor leveranciersafhankelijkheid. Dat verdient een plaats in de aankoopbeslissing, niet in de technische bijlage.
• Ze schaft dubbele invoer tussen systemen af. Als een klantadres in drie tools ingetikt wordt, is dat bijna nooit omdat ze verbinden onmogelijk was. Het is omdat niemand de koppeling afgebakend heeft.
• Ze maakt automatisering mogelijk zonder iets te vervangen. Twee systemen verbinden die elk hun werk goed doen, kost doorgaans veel minder dan migreren naar één suite die beide ongeveer doet.
• In sommige gevallen is het voortaan een wettelijke noodzaak. Gestructureerde elektronische facturatie in België vereist dat facturen vertrekken en binnenkomen als machineleesbare data. Die weg loopt via een interface, of u die nu API of toegangspunt noemt.

De ongemakkelijke keerzijde is dat een integratie nooit af is. De andere kant van het contract is van iemand anders, die een veld zal wijzigen, een versie zal intrekken of een limiet op het aantal aanroepen zal aanscherpen volgens zijn planning en niet de uwe. Een integratie budgetteren als een eenmalig project is de meest voorkomende planningsfout, en die duikt zes maanden later weer op als dringende correctie waarvoor niemand iets voorzien had.

Hoe het werkt

Vijf mechanismen dekken bijna alles wat een koper moet begrijpen.

Request en response. De afnemer stuurt een request met de naam van een operatie en de parameters ervan. De aanbieder stuurt een gestructureerde response terug, plus een status die het succes aangeeft of de reden van de mislukking. Mislukkingen correct afhandelen is het grootste deel van het werk.

Authenticatie. Elke aanroep bewijst wie hem doet, meestal met een sleutel of een token, en die credentials hebben een reikwijdte. Een goed ontworpen integratie krijgt de smalste toegang waarmee ze kan werken, waardoor een gecompromitteerde sleutel geen volledig lek wordt.

Limieten op aanroepen. Aanbieders begrenzen het aantal aanroepen per minuut of per dag. Dat is een functionele beperking en geen detail: een integratie die ontworpen is zonder de limiet te kennen, werkt in de test en faalt op de eerste drukke dag.

Versiebeheer. Een aanbieder die zijn gedrag wijzigt, breekt al zijn afnemers. Serieuze aanbieders publiceren versies en een deprecatiebeleid met de opzegtermijn die ze hanteren. Wie er geen heeft, zal ooit uw integratie zonder waarschuwing breken, en dat risico hoort bij de evaluatie.

Webhooks. De omgekeerde richting. In plaats van dat uw systeem elke vijf minuten vraagt of er iets veranderd is, laat de aanbieder u weten wanneer het gebeurt. Goedkoper, sneller en minder fragiel dan regelmatig bevragen, en hun afwezigheid betekent meestal een rij geplande taken die niemand wil onderhouden.

Implementatie

De lijst hieronder is geschreven als vragen die u stelt vóór u tekent, omdat dat het moment is waarop de antwoorden nog iets veranderen.

1. Is de documentatie openbaar, en leesbaar vóór de aankoop? Documentatie die pas na ondertekening toegankelijk is, is een alarmsignaal, geen administratieve formaliteit.
2. Zit de API-toegang erbij of wordt ze als optie verkocht? Ze apart factureren is gebruikelijk en legitiem. Het ontdekken nadat u het hoofdcontract getekend hebt, is geen goede positie.
3. Stelt ze alles beschikbaar wat u nodig zou hebben om te vertrekken? Leestoegang tot uw eigen historiek telt meer dan de operaties die in de mode zijn. Test een echte export voor u zich vastlegt.
4. Wat is de limiet op aanroepen, en kan ze uw pieken aan? Niet uw gemiddelde. Maandafsluitingen en seizoenspieken zijn het moment waarop de limiet bijt.
5. Wat is het deprecatiebeleid? Negentig dagen opzegtermijn en een changelog is een aanvaardbaar antwoord. Geen beleid betekent dat uw integratie gepland staat om te breken op een moment dat iemand anders kiest.
6. Zijn er webhooks beschikbaar? Zonder webhooks moet u in een lus bevragen, wat meer kost, trager reageert en taken toevoegt die onderhouden moeten worden.
7. Budgetteer het onderhoud, niet alleen de oplevering. Een integratie is een abonnement op de roadmap van iemand anders. Voorzie een kleine terugkerende enveloppe in plaats van een noodgeval.

Gerelateerde technologieën en tools

• REST en GraphQL: de twee dominante stijlen. REST stelt vaste operaties beschikbaar, GraphQL laat de afnemer precies de velden opgeven die hij wil. De keuze beïnvloedt de inspanning, niet de mogelijkheden.
• OpenAPI: de standaard om een interface te beschrijven in een machineleesbaar bestand, waaruit documentatie en clientcode gegenereerd worden. De aanwezigheid ervan is een goede indicator van hoe serieus een aanbieder zijn contract neemt.
• Webhooks: meldingen op initiatief van de aanbieder, waardoor bevragen in een lus overbodig wordt.
• OAuth 2.0: de standaard voor gedelegeerde autorisatie, waarmee een integratie namens een gebruiker kan handelen zonder diens wachtwoord te kennen.
• API-gateways: de laag die authenticatie, rate limiting en logging centraliseert vóór meerdere interfaces.
• MCP: de opkomende standaard om tools en data beschikbaar te stellen aan taalmodellen, die bovenop bestaande API’s komt in plaats van ze te vervangen.

Conclusie

Een API is een commercieel engagement, uitgedrukt in technische termen. Beoordeel ze zoals elk engagement van een leverancier: wat er beloofd wordt, wat het kost, welke opzegtermijn vóór een wijziging geldt, en wat u kunt meenemen als u vertrekt.

De vraag die u vóór een softwareaankoop stelt, is dus niet of het product een API heeft. Het is wat die API u laat meenemen. Een leverancier die duidelijk antwoordt en u een echte export laat testen, biedt een relatie van een andere aard dan een leverancier die zijn interface als premiumoptie behandelt. Dat verschil kost niets om na te gaan en kost heel veel als u het te laat ontdekt.