Waarom bedrijven kiezen voor directe API-koppelingen
De redenering is begrijpelijk. Een middleware-platform als MuleSoft of Azure Integration Services brengt licentiekosten, een leercurve en een extra beheerlaag mee. Als je twee of drie systemen aan elkaar wilt knopen, voelt dat als een voorschot op complexiteit die je nog niet hebt. Dan lijkt een directe REST-koppeling tussen je WMS en je transportpartner de pragmatische weg. Je bouwt een endpoint aan, schrijft een kleine service die berichten doorstuurt, en je bent in productie voor de kwartaalgrens. Dat werkt. Totdat het niet meer werkt.
Valkuil 1: foutafhandeling zonder vangnet
Bij point-to-point integraties is de foutafhandeling de verantwoordelijkheid van de koppeling zelf. Er is geen centrale broker die berichten opvangt als een endpoint tijdelijk onbereikbaar is. In de praktijk betekent dit dat een time-out aan de kant van de ontvanger een bericht stil laat verdwijnen, tenzij je zelf retry-logica, dead-letter queues en alerting hebt ingebouwd. Dat is precies het werk dat middleware voor je doet. Zonder dat fundament bouwen teams vaak iets halfslachtigs: een log-tabel in de database, een dagelijkse handmatige controle, of gewoon de aanname dat beide kanten altijd beschikbaar zijn. Op een drukke operationele dag, als een leveranciers-API een onderhoudsvenster inlast dat niet was gecommuniceerd, komen de gaten aan het licht.
Valkuil 2: versiebeheer van endpoints
Externe systemen updaten hun API's. Soms met een versienummer in het pad, soms niet. Als je vijf directe koppelingen hebt gebouwd naar vijf leveranciers of partners, en drie van hen brengen een API-update uit in hetzelfde kwartaal, dan heb je drie aparte projectjes om bij te werken. Zonder middleware-platform heb je geen adapter-laag die de vertaling centraliseert. Elke koppeling is een eigen codebase met eigen aannames over het dataformaat. Bij een klein landschap van twee of drie koppelingen is dat beheersbaar. Bij tien of meer wordt het een stille technische schuld: de integraties draaien, maar niemand weet precies welke versies van welke endpoints in gebruik zijn, en updates van leveranciers worden reactief opgepakt in plaats van gepland.
Valkuil 3: monitoring zonder centrale laag
Middleware-platforms bieden standaard een dashboard: berichtenvolume, latency, foutratio's, per koppeling. Zonder zo'n platform moet je die observability zelf bouwen of missen. Wat we in de praktijk zien: de eerste koppelingen krijgen logging mee, de derde en vierde iets minder, de vijfde haast niets omdat de druk op het project hoog was. Het gevolg is dat je operationeel pas weet dat een koppeling stil ligt als iemand aan de andere kant belt. Proactieve monitoring, alerts bij stilstaande berichtstromen of afwijkende volumes, dat vergt discipline en bouwtijd die in directe koppelingen structureel onderschat wordt.
Wanneer integraties bouwen zonder middleware juist wél de slimme keuze is
Eerlijk is eerlijk: er zijn goede redenen om geen middleware-platform te gebruiken. Als je landschap klein en stabiel is, zeg twee of drie koppelingen met systemen waarvan de API's volwassen en goed gedocumenteerd zijn, dan voegt een platform kosten en beheeroverhead toe zonder evenredige waarde. Als de koppeling intern is, tussen systemen die je zelf beheert en versieert, heb je ook geen centrale broker nodig. En als je een greenfield systeem bouwt waarbij de architectuur van begin af aan API-native is ontworpen, kun je de integratieverantwoordelijkheid onderbrengen in het kernsysteem zelf, in plaats van te delegeren aan een los platform. Het criterium is eenvoudig: gaat het integreatielandschap groeien, zijn de externe partijen wisselend of onvoorspelbaar in hun API-beheer, dan betaalt een centrale laag zich terug. Blijft het stabiel en klein, dan is directe koppeling gewoon engineering.
Wat je kunt doen als je toch zonder middleware bouwt
Als de keuze voor directe API-koppelingen bewust en gefundeerd is, zijn er drie dingen die het verschil maken. Ten eerste: bouw foutafhandeling en retry-logica in vanaf dag één, niet als nawerk. Ten tweede: leg per koppeling vast welke API-versie in gebruik is en maak een register, ook al is het een simpele tabel. Ten derde: stel alerting in op berichtvolume, niet alleen op HTTP-foutcodes. Een koppeling die stilstaat geeft vaak geen fout terug, hij stuurt simpelweg niets meer. Die drie maatregelen lossen de grootste risico's op zonder dat je een volledig middleware-platform nodig hebt. Ze kosten tijd bij de bouw, maar die tijd win je terug zodra de eerste externe API-update of het eerste incident binnenkomt.