De verschillen tussen API's en berichten voor applicatiecommunicatie

Phil Wilkins | Cloud Developer Evangelist, Oracle | december 2022

Software moet met andere software praten. Soms moet software in het ene deel van een toepassing diensten aanvragen of gegevens uitwisselen met een ander deel van de toepassing. Of één toepassing moet diensten aanvragen of gegevens uitwisselen met een geheel andere toepassing.

Voor deze typen communicatie worden doorgaans twee mechanismen gebruikt: API's (Application Programming Interfaces) en berichten.

De verschillen tussen API's en berichten kunnen soms verwarrend worden. Dat komt doordat de termen op veel meerduidige manieren worden gebruikt. De afkorting API zelf heeft een expliciete betekenis, maar om redenen die we hieronder zullen uitleggen, heeft de term verschillende betekenissen. Berichten is een term die vaak erg breed wordt gebruikt voor bijna elke communicatie tussen systemen onderling. Laten we dus duidelijk maken wat echt wordt bedoeld met API's en berichten.

Een gedetailleerde definitie van API's

Een API is in grote lijnen het contract waarin wordt gedefinieerd hoe software serviceaanvragen kan ontvangen en beantwoorden. Dat contract wordt opgesteld door de software-ontwikkelaars.

Klinkt dat eenvoudig? Dat is op één niveau. In de praktijk kan de impliciete betekenis van een API veranderen naar gelang het gespreksonderwerp. Als we de afkorting erbij nemen, is API de interface of het "contract" waarmee het ene stukje software met een ander stukje kan communiceren . Soms is het gesprek over een API gericht op architectuurdefinities op hoog niveau. Soms uiterst gedetailleerd en met een beschrijving van de specifieke manieren waarop ontwikkelaars de API kunnen implementeren.

Sommige boeken en artikelen over API's gebruiken een analogie waarbij een API een deur is en de API-kenmerken de deur beschrijven. Het kan bijvoorbeeld een winkeldeur zijn, die vanzelf opengaat of een extreem beveiligde kluisdeur. Het contract van een applicatie, de kenmerken van de deur, moet helpen bij het beschouwen van overwegingen, zoals:

  • Wat doet de API op hoog niveau? In onze deur-analogie: Gaat de API open zonder dat de gast hoeft te stoppen en iets moet aanraken (winkeldeur) of controleert de API de toegang en beschermt de API wat er achter de deur zit (kluisdeur)?
  • Welke payloads (gegevens die worden verzonden) moeten worden ondersteund om de software te laten presteren? De software kan bijvoorbeeld een bankrekeningnummer en een beveiligingsautorisatie ontvangen en reageren met het saldo op die bankrekening.
  • Welke gegevens moeten worden uitgewisseld om die service uit te voeren? Het is bijvoorbeeld belangrijk om precies te definiëren hoe een geldig rekeningnummer en een geldige beveiligingsautorisatie eruit zien en om de inhoud van de respons te definiëren. Zulke details tellen, want meerduidigheid kan tot fouten leiden.
  • Wat is het adres van de deur? Dit betekent meestal hoe de URI (Universal Resource Identifier) voor de aanvraag wordt gevormd. Dat wil zeggen: Hoe praat de aanvrager eigenlijk met de API?
  • Welke protocollen worden gebruikt voor de communicatie? Deze kunnen variëren van bekende technologieën, zoals HTTP en FTP, tot speciale protocollen, zoals STOMP en QUIC.
  • Aan welke voorwaarden moet de API-gebruiker voldoen? Dit kan encryptiedetails omvatten; een limiet voor het aantal keren dat API's worden aangeroepen of verrekenmechanismen voor commerciële services.
  • Wat belooft de API? Dit kan servicegaranties voor de API omvatten, zodat een aanvraag binnen een bepaalde periode wordt bevestigd of uitgevoerd.

Berichten definiëren in applicatieontwikkeling

Hoewel API's de voorwaarden definiëren voor het verzenden en ontvangen van serviceaanvragen, is het berichtenverkeer het proces om informatie van het ene naar het andere systeem te verzenden. Het sleutelwoord is proces.

U moet het zo zien:

  • Berichtenverkeer is het proces waarin een deel van de informatie (de boodschap) van de serviceaanvrager naar de serviceprovider worden verzonden (vaak via een derde partij, die we de broker noemen).

    Een alledaagse analogie is een bedrijf dat een sms naar een klant stuurt. De serviceprovider moet het telefoonnummer van de ontvanger kennen, zodat de mobiele provider het bericht kan afleveren. De payload zelf kan vanuit het perspectief van de mobiele provider echter van alles zijn. De mobiele provider hoeft niet te weten of uw sms Engels, Spaans, Japans of een emoji is.

  • Berichtenverkeer verwijst naar alle acties achter de schermen om een bericht van de afzender naar de klant te sturen.

    U en uw klanten hoeven niet te begrijpen hoe het berichtenproces werkt. U vertrouwt erop dat de mobiele providers en telefoonfabrikanten hun werk goed hebben gedaan. En ook de provider hoeft de payload niet te kennen; hij moet er gewoon voor zorgen dat die in goede en bruikbare staat aan de juiste persoon wordt geleverd.

Het is belangrijk te herhalen dat de meeste berichtenplatforms niet bezorgd zijn over de payload, zolang die maar binnen de beperkingen van de technologie past. Om terug te keren naar onze analogie: het maakt de smartphone en mobiele provider niet uit of uw tekst Engels of een emoji is.

Bekijk meer informatie over de samenstelling van API's, API-platforms en API-beheer.

API's en berichten werken samen in bedrijfssystemen

Bedrijfssoftwaresystemen bestaan uit meerdere, afzonderlijk uitvoerbare processen en vereisen daarom een communicatie tussen de processen onderling (IPC). De communicatie kan complex zijn, waarbij het vaak heen en weer gaat met veel API-aanroepen en waarvoor veel strikt geformatteerde gegevens nodig zijn om een transactie uit te voeren. Deze transacties moeten zorgvuldig worden georkestreerd en uitgevoerd om aan een zakelijke behoefte te voldoen.

Denk bijvoorbeeld aan een klantinkooporder. Het proces moet toegang krijgen tot de klantendatabase, de inventarisdatabase, het boekhoudsysteem, een facturatiesysteem en het systeem voor het afschrijven van creditcards, het aanpassen van de voorraad en de klantrekening, het aanmaken van een magazijnaanvraag en het starten van een verzendaanvraag. Deze moeten in de juiste volgorde en correct worden uitgevoerd.

Vroeger werden deze interacties uitgevoerd via een bepaalde vorm van gedeelde opslag, zoals een bestandssysteem of een database. In modernere bedrijfssystemen kunnen de processen echter direct met elkaar communiceren, waardoor het proces wordt versneld en problemen worden opgelost (bijv. als de voorraad voor uw order al aan eerdere orders is toegewezen).

Synchroon en asynchroon gedrag

We kunnen onze communicatie als synchroon of asynchroon karakteriseren. Synchrone communicatie betekent dat alle betrokken partijen aanwezig moeten zijn en terug moeten kunnen zenden. In ons bestelvoorbeeld moeten de elektronische betalingssystemen beschikbaar zijn voor een real-time interactie. In andere gevallen kan de communicatie asynchroon verlopen, waardoor de partijen van de communicerende systemen niet gelijktijdig aanwezig hoeven te zijn. Zo werkt het als we e-mails naar elkaar schrijven. Om een asynchrone communicatie mogelijk te maken, hebben we een intermediair nodig om informatie heen en weer te laten gaan.

Deze complexe zakelijke berichtensystemen zijn er in diverse vormen:

  • Servicebus. De servicebus fungeert als de lijm tussen verschillende processen en voert een orkestratie tussen die processen uit, zoals in de hierboven genoemde complexe transactie. Servicebussystemen omvatten doorgaans functies met toegevoegde waarde, zoals de mogelijkheid om payloads van het ene formaat naar het andere te vertalen (Engels naar Frans in onze sms-analogie), berichten te routeren naar gelang hun inhoud of zelfs beslissingen te nemen op basis van de status van de complexe transactie. De taken A en B kunnen bijvoorbeeld parallel worden uitgevoerd; taak C uitvoeren als taak B is afgerond; taak D uitvoeren; menselijke hulp inroepen als taak D mislukt.

    Het berichtenverkeer via een servicebus wordt soms omschreven als een Smart Pipe, omdat die extra informatie bevat over het routeren en plannen van berichten in de 'pipe' tussen de aanbieders en consumenten. Dit wordt ook wel orkestratie genoemd.

    Schema servicebus, omschrijving hieronderDe berichtenaanbieder roept de servicebus aan door een bericht te leveren. De servicebus neemt vervolgens het bericht en routeert het naar de consumenten. Tijdens de routering kan het bericht door programmatuur worden getransformeerd en gefilterd.

    Een ander woord voor servicebus is messagebus. Toen deze technologieën aanvankelijk tot servicegerichte architectuur-oplossingen (SOA) uitgroeiden, waren er enkele verschillen tussen message- en servicebussen. Tegenwoordig verschillen ze niet echt meer. Hun naam wordt daarom steeds vaker afgekort tot bus.

  • Webservices: in de breedste zin van het woord verzorgen web services een directe synchrone communicatie tussen twee processen, doorgaans met behulp van TCP- en HTTP-protocollen (of variaties, zoals HTTPS en HTTP/2). De consument en client worden gerealiseerd als point-to-point-verbindingen (hoewel het gebruikelijk is dat de provider meerdere simultane clientverbindingen ondersteunt). Er kunnen proxies (van netwerkfirewalls naar API-gateways, en webcaches) en netwerkintermediairs (switches en routers) tussen de twee processen zitten, maar noch de provider noch de consument hebben daar weet van.

    Schema van webservices, omschrijving hieronderDe berichtenaanbieder communiceert direct met de consument. Het verzendproces is afhankelijk van de beschikbaarheid van beide partijen.
  • Message brokers:Message brokers zijn intermediairs tussen aanbieders en consumenten van berichten, die eigenschappen delen met zowel servicebussen als webservices.

    Brokers zitten tussen de afzender en de ontvangers van de berichten. Ze ontvangen het gecommuniceerde bericht en slaan het op tot de ontvangers het hebben geconsumeerd. Dit betekent dat het bericht kan worden verzonden zonder dat u zich zorgen hoeft te maken over de onmiddellijke beschikbaarheid van de ontvanger. Als gevolg daarvan wordt dit soort communicatie vaak asynchroon of "fire and forget" genoemd, omdat u er zeker van kunt zijn dat het bericht op een bepaald moment wordt afgeleverd, zolang de broker operationeel blijft.

    De overeenkomst met webservices zit in het feit dat de verbinding tussen klant en broker wordt beschouwd als een point-to-point verbinding, waarbij de message broker functioneel onzichtbaar is.

    De gelijkenis met een servicebus komt voort uit het feit dat de broker een service met toegevoegde waarde biedt: namelijk het vasthouden van ontvangen berichten tot de ontvangers beschikbaar zijn. In tegenstelling tot een robuustere servicebus, heeft een message broker een minimale intelligentie voor alleen eenvoudige dingen, zoals weten welke bestemmingen een bepaald bericht willen ontvangen en wat te doen als de bestemming het bericht niet tijdig consumeert.

    Communicatie via een broker wordt communicatie via een Dumb Pipe genoemd. Omdat de brokers een minimale intelligentie hebben, moeten de eindpunten begrijpen wat nodig is wanneer een bericht moet worden verzonden of ontvangen. Deze methode noemen we choreografie (in tegenstelling tot de intelligentere orkestratie van een servicebus).

    Schema van message brokers, beschrijving hieronderDe berichtenaanbieder geeft zijn bericht aan de broker. De broker bewaart vervolgens het bericht totdat de consumenten het hebben aangevraagd of het kunnen ontvangen. De aanbieder is niet afhankelijk van de consument.

De rol van streaming in zakelijke berichten

Voor deze discussie kan streaming worden gezien als een vrij specialistisch berichtenverkeer, hoewel sommige streamingtechnologieën een element van dataverwerking kunnen ondersteunen. Streaming wordt in deze context beschreven als het via IPC-technologie verzenden van een continue stroom events naar dezelfde bestemming(en), ongeacht of webservices of message brokers de communicatie regelen. (Hier zijn heel zelden servicebussen bij betrokken, omdat er te snel te veel data wordt uitgewisseld, waarbij de extra intelligentie van een servicebus niet nodig is.)

Naast een continue datastroom, verwacht het streamen meestal een connectiviteit in vrijwel realtime of met een lage latentie. Het zal u dus niet verbazen dat diensten zoals Netflix van oudsher videostreaming worden genoemd. U wilt beslist niet dat de afgespeelde video stopt en start terwijl er nieuwe stukjes video worden verzonden vanuit de provider of terwijl een message broker de video van het ene in het andere formaat omzet

Gebruikelijke technologieën voor het streamen van webservices zijn WebSockets, gRPC-streams en GraphQL-abonnementen. Als het gaat om berichtenverkeer via brokers (met technologieën zoals Kafka), kunt u soms de werkwijze van de broker benutten om naar een "slice" van de verzonden events te kijken. Dit helpt u waardevolle inzichten te verzamelen, waaronder informatie over de stream zelf, vandaar de term streaminganalyse.

Hoewel de programmatuur van de streaminganalyse wellicht verfijnd is, voert de message broker geen beslissings- of berichtmanipulatie uit. Daarom wordt de broker nog steeds als "dom" beschouwd. Zulke mogelijkheden voor streaminganalyse worden vaak toegepast met technologieën zoals Kafka Streams.

Industriestandaarden voor API's en berichten

API's en berichtensystemen zijn eenvoudig te beschrijven, maar zeer complex in de details en technische kenmerken. Meerduidigheid wordt niet geduld, wat leidt tot een reële behoefte aan nauwkeurige industriestandaarden en documentatie en idealiter de beste toepassing van deze normen.

Dit is al ruim tien jaar een ontwikkelingsgebied, met name voor API's. De industrie omarmt de OpenAPI-specificatie voor REST-gebaseerde API's, die een vorm van webservices zijn, en waarschijnlijk de meest voorkomende soorten API's die we in moderne bedrijfssoftware tegenkomen.

Met API's (en streaming) beschikt u over een aantal aanvullende standaarden voor het definiëren en beschrijven van aspecten van berichten en de overdracht ervan. Ze omvatten protocolbuffers (ook wel Protobuf genoemd en gebruikt met gRPC) en meer recent GraphQL, JSON Schema en YAML.

In het domein van asynchrone berichten is het de afgelopen jaren gelukt om het eens te worden over de definitie AsyncAPI, die ideeën uit OpenAPI en andere opkomende standaarden heeft aangepast om aan de vele vereisten voor het berichtenverkeer te voldoen.

Moderne gedistribueerde applicaties worden geïmplementeerd als een verzameling services, die uit losse stukjes software bestaan, soms op dezelfde servers, soms niet. API's zijn een manier om deze stukjes software met elkaar te laten praten om services van elkaar te vragen of informatie uit te wisselen. Berichtensystemen bieden de infrastructuur om asynchrone communicatie te vergemakkelijken en intelligente intermediairs te leveren voor API-aanroepen, die erg eenvoudig kunnen zijn (zoals smartphone-teksten werken) of extreem complex (zoals de orkestratie voor complexe bedrijfstransacties in meerdere stappen). Om nog maar te zwijgen van de gedistribueerde services die via API's rechtstreeks met elkaar communiceren. Gelukkig laten de opkomende technieken en standaarden het toe dat we voor alles API's gebruiken, van database-aanroepen tot mediastreaming. En deze API's en berichtenstandaarden blijven zich ontwikkelen, waardoor de overgang naar moderne gedistribueerde software-architecturen sneller, gemakkelijker en veiliger wordt.