Een API is een afgesproken manier waarop software functies of gegevens van andere software gebruikt. Je bestelapp kan er bijvoorbeeld voorraad mee opvragen, zonder zelf het voorraadsysteem te worden. In onze gids voor custom software lees je hoe zulke onderdelen in een applicatie passen. Zoek je vooral naar de uitvoering, ga dan verder met een API-koppeling laten maken of de uitleg over software koppelen.
Wat betekent API precies?
API staat voor Application Programming Interface. Je kunt het zien als een afgesproken ingang voor software: deze vragen mag je stellen, deze gegevens moet je meesturen en zo komt het antwoord terug. Cloudflare beschrijft hoe programma’s op die manier elkaars functies gebruiken.
Een API is dus geen apart soort database. En het is ook niet automatisch een scherm waarin medewerkers werken. De gebruiker ziet bijvoorbeeld een voorraadmelding; op de achtergrond vraagt de app die informatie op.
API’s bestaan ook binnen software en besturingssystemen. MDN maakt onder meer onderscheid tussen functies van de browser en API’s van externe diensten. In gesprekken over bedrijfssoftware bedoelt een leverancier met “de API” vaak een webinterface waarmee andere systemen gegevens kunnen opvragen of acties kunnen uitvoeren.
Hoe werkt een API in een herkenbaar voorbeeld?
Stel dat een medewerker een artikel kiest in een bestelapp. De app vraagt het voorraadsysteem of dat artikel beschikbaar is. Het voorraadsysteem beantwoordt die vraag en de app toont de uitkomst. Dit is een vereenvoudigd denkvoorbeeld, geen klantcase.
In dat gesprek heet de vraag een request, of verzoek. Het antwoord heet een response. De app stuurt het verzoek naar het juiste adres van de API, het endpoint. MDN legt bij netwerkverzoeken uit hoe software een antwoord ontvangt en controleert of het verzoek is gelukt.
Wat de medewerker daarna mag doen, is een aparte afspraak. Beschikbaarheid opvragen is iets anders dan voorraad reserveren. Misschien mag de API beide, misschien alleen het eerste. “Er zit een API op” vertelt je dat nog niet.
Ook de betekenis van het antwoord moet duidelijk zijn. Is “beschikbaar” de voorraad in het magazijn, of de voorraad die nog niet aan een andere klant is beloofd? Een technisch correct antwoord kan voor de medewerker de verkeerde betekenis hebben. Laat de leverancier daarom het voorbeeld uitwerken met de begrippen die jouw team gebruikt.
Welke begrippen kom je in een voorstel tegen?
De onderstaande termen beschrijven verschillende delen van dezelfde uitwisseling. Je hoeft ze niet zelf te kunnen bouwen, maar ze helpen je een voorstel te lezen.
| Begrip | Betekenis in het voorbeeld | Vraag die je ermee kunt stellen |
|---|---|---|
| API | De aangeboden ingang van het voorraadsysteem | Welke functies zijn beschikbaar? |
| Endpoint | Het adres voor een bepaalde vraag of handeling | Is voorraad opvragen beschreven? |
| Request | De vraag van de bestelapp | Welk artikelnummer moet worden meegestuurd? |
| Response | Het antwoord van het voorraadsysteem | Welke voorraadstatus krijgen we terug? |
| API-key of token | Een toegangsmiddel, afhankelijk van de dienst | Welke rechten krijgt de bestelapp? |
| Documentatie | Uitleg voor de bouwer die de interface gebruikt | Zijn voorbeelden en foutmeldingen beschreven? |
Een losse API-link in een offerte is weinig houvast. Je wilt weten welke handeling ermee wordt uitgevoerd en wat het resultaat betekent voor je proces. Vraag om een korte demonstratie met één herkenbaar artikel of dossier. Dan wordt snel zichtbaar of jullie over hetzelfde praten.
Wat is het verschil tussen een API en een koppeling?
De API biedt de mogelijkheid; een koppeling gebruikt die mogelijkheid in een werkend proces. Vergelijk het met een ingang en de route die je erdoorheen aflegt. Alleen een ingang hebben zorgt nog niet dat informatie op het juiste moment bij de juiste ontvanger aankomt.
Bij ons voorraadvoorbeeld moet iemand vastleggen wanneer de bestelapp de voorraad opvraagt, hoe artikelnummers overeenkomen en welke melding verschijnt als er geen antwoord komt. Dat hoort bij de koppeling en de applicatie eromheen.
Niet ieder systeem hoeft daarvoor dezelfde API aan te bieden. Een applicatie kan een API van een ander systeem aanroepen. De beschikbare mogelijkheden aan beide kanten moeten wel passen bij de gewenste handeling. Een app die alleen informatie toont, stelt andere eisen dan een proces dat gegevens terugschrijft.
Het type product blijft een andere keuze. Een webapp, SaaS-product of custom platform kan allemaal API’s gebruiken. De aanwezigheid van een API zegt niet of een pakket voor jouw hele bedrijf geschikt is.
Betekent een open API dat iedereen erbij kan?
Nee. “Open” kan betekenen dat de interface voor externe ontwikkelaars is bedoeld of openbaar is beschreven. Dat maakt alle gegevens nog niet openbaar. Vraag altijd wat de aanbieder precies bedoelt met die term.
Er zijn API’s voor intern gebruik, voor toegelaten partners en voor een breder publiek. Daarnaast bestaan technische vormen zoals REST en SOAP. Die indelingen beantwoorden verschillende vragen: wie mag de interface gebruiken, en hoe is de communicatie ingericht?
Voor jou telt vooral wat je account mag doen. Een toegangsmiddel dat alleen voorraad mag lezen, hoeft geen klantgegevens te kunnen wijzigen. GitHub adviseert voor zijn API onder meer om toegangsrechten te beperken en geheime toegangsmiddelen niet in openbare code te zetten. Laat jouw leverancier uitleggen hoe sleutels worden bewaard, vervangen en ingetrokken.
Stuur een geheime API-key daarom niet mee in een algemene offerteaanvraag of screenshot. De vraag “welke toegang is nodig?” kun je beantwoorden zonder de sleutel zelf te delen.
Wat is het verschil tussen een API-verzoek en een webhook?
Bij een gewoon verzoek vraagt je software zelf om informatie. Een webhook laat de andere kant een bericht sturen wanneer een afgesproken gebeurtenis plaatsvindt. GitHub licht dat verschil toe als het verschil tussen periodiek navragen en een gebeurtenismelding ontvangen.
In het voorraadvoorbeeld kan de app de stand opvragen wanneer een medewerker een artikel opent. Als het systeem geschikte webhooks aanbiedt, kan een voorraadwijziging ook aanleiding zijn voor een bericht aan de app. Of dat nodig is, hangt af van het werk. Een dagelijks overzicht hoeft misschien minder actueel te zijn dan een reservering tijdens een bestelling.
Een webhook is geen belofte dat een heel proces altijd goed afloopt. De ontvangende software moet het bericht nog verwerken. Vraag daarom welk moment de medewerker op het scherm ziet: het verzenden van het bericht, de ontvangst of het werkelijk opslaan van de wijziging.
Wat gebeurt er als een verzoek mislukt?
Dat hangt af van de fout en de gemaakte afspraken. Een onbekend artikelnummer vraagt een andere reactie dan een tijdelijke verbindingsstoring. De medewerker heeft in beide gevallen een bruikbare melding nodig, maar op de achtergrond is de oplossing anders.
Opnieuw proberen klinkt eenvoudig. Bij een handeling die iets aanmaakt, kan dat een dubbel resultaat geven als het eerste verzoek wel is verwerkt maar het antwoord verloren ging. Stripe beschrijft idempotency keys als middel om zulke herhaalde verzoeken veilig te herkennen. Dat is een voorbeeld van een voorziening bij één aanbieder, geen eigenschap die je bij iedere API mag aannemen.
Laat bij een demonstratie dus ook zien wat de gebruiker ziet wanneer het antwoord uitblijft. Moet die wachten, mag die opnieuw klikken of neemt een beheerder het over? Dat gesprek levert meer op dan alleen de vraag of de verbinding “realtime” is.
Welke vragen stel je voordat je software kiest?
Begin met de handeling die je nodig hebt. “Voorraad kunnen opvragen voor de bestelapp” is toetsbaar. “Een moderne API” is dat nauwelijks. Leg vervolgens naast elkaar wat jouw team verwacht en wat de aanbieder daadwerkelijk beschikbaar stelt.
Vraag of de benodigde functie onder jouw abonnement valt, welke gebruikslimieten gelden en wie wijzigingen aankondigt. Een API kan afzonderlijke voorwaarden hebben. Vraag ook wie verantwoordelijk is wanneer de aanbieder een oude versie uitfaseert: de pakketleverancier, jouw ontwikkelaar of jullie samen.
Bij eigen software horen die afspraken bij de overdracht. Wie beheert toegang, waar staat de documentatie en kan een volgende ontwikkelaar ermee verder? Onze uitleg over code-eigendom en afhankelijkheid van leveranciers helpt om daar concrete afspraken over te maken. De API is maar één onderdeel van die overdracht.
Hoe begin je concreet?
Schrijf één voorbeeld uit: welke medewerker doet iets, welke informatie is nodig en uit welk systeem moet die komen? Vraag de leverancier daarna om precies die route te laten zien, inclusief het antwoord wanneer iets niet lukt.
Is daarvoor een eigen applicatie nodig, dan kun je maatwerk software laten maken rond het proces. Bij TopDevs geldt: de code is en blijft van jou. Begin met de vraag die de software moet beantwoorden; de technische vorm volgt uit wat daarvoor nodig is. Plan een gesprek.
