Om je applicatie te integreren in je bedrijfsprocessen wil je deze koppelen met andere systemen. Maar doe je dat met een REST API direct vanuit je applicatie of maak je gebruik van een integratielaag? In dit blogartikel kom je erachter wanneer het handig is om te kiezen voor een integratielaag en welke mogelijkheden dat met zich meebrengt.
Wanneer je een applicatie hebt aangeschaft, heb je weinig invloed op wat een API doet. Je kunt deze niet aanpassen. Wanneer je een applicatie zelf hebt gebouwd, kun je een REST API ontwerpen zoals je wilt. Of je REST in je eigen applicatie verwerkt of er een integratielaag voorzet, is afhankelijk van wat je applicatie aanbiedt en hoe generiek deze is. Bij een applicatie die een standaard output levert of die maar één afnemer heeft, kun je ervoor kiezen de interface aan de applicatie toe te voegen.
Als je meer dan één afnemer wilt bedienen of applicaties aan elkaar wilt koppelen met een API, is het slimmer om hier een integratielaag tussen te plaatsen. Een REST API uit een integratielaag kun je namelijk eenvoudig meerdere keren ‘exposen’. Bovendien hoef je bij vervanging van een applicatie niet ook nog eens je hele API te veranderen. Of je kiest voor REST in je eigen applicatie of in een integratielaag is dus volledig afhankelijk van het doel van je API.
Worstel je met een specifiek integratievraagstuk? Of heb je een vraag over bepaalde systemen, applicaties of Integration as a Service?
{{cta('987f4747-d3fb-4be6-9c93-764a4c7afafc')}}
Wanneer je ervoor kiest om een integratielaag te plaatsen voor je applicatie, dan vang je daarmee de manco's van het achterliggende systeem op. Als een applicatie niet goed kan omgaan met duplicates, dan regel je daar een methode voor in de integratielaag. In die laag mogen namelijk de workarounds zitten, die wil je niet in je applicatie zelf. Dat geldt voor meerdere mogelijkheden die je in een integratielaag terugvindt:
Granulariteit
Hoe je je data structuur geeft en hoeveel data je op verzoek deelt, heeft te maken met de granulariteit van je REST API. Die is namelijk lastig aan te passen. Wanneer je alleen een adres nodig hebt, krijg je misschien wel alle persoonsgegevens terug. Dat geldt ook voor de granulariteit van je applicatie: past die bij je objecten en collecties? Met een integratielaag regel je welke data je deelt, dat verschilt potentieel per afnemer. Wanneer je dat in je applicatie moet doen, is dat veel werk.
Loskoppeling functionaliteit van techniek
In een integratielaag kun je technische details, documentatie, beheer, validatie en autorisatie verwerken, zodat een REST API vooral doet wat deze moet doen. Door die ontkoppeling is het gemakkelijker om nieuwe componenten op elkaar aan te sluiten of weer van elkaar te scheiden.
Flexibiliteit bij upgrades
Dit is al kort aan bod geweest, maar bij een upgrade van een systeem heb je ook een nieuwe versie van je REST API nodig. Door hier een integratielaag tussen te zetten, is dat niet nodig. Het functionele deel van de API koppel je aan de achterkant met de nieuwe versie van je systeem. Een integratielaag maakt je veel flexibeler én bespaart je afnemers veel aanpassingen.
Orkestratie
Wanneer je voor een verzoek informatie uit meerdere systemen nodig hebt, dan is dat lastig wanneer je een REST API in je eigen applicatie hebt. Je wilt namelijk liever niet dat een applicatie op zijn beurt data uit een ander systeem moet ophalen om zo aan de vraag te kunnen voldoen. Dat maakt het complex en je hebt geen inzicht in wat er aan de achterkant gebeurt. Met een integratielaag verlopen die verzoeken eventueel parallel aan elkaar en wordt informatie veel efficiënter verzameld en gedeeld en houd je overzicht.
Mapping
Deze functionaliteit vind je terug in de integratielaag. Stel, je systemen zijn in het Nederlands, maar je API's in het Engels. In de tussenlaag regel je dan dat de taal zonder veel moeite wordt omgezet.
Wil je meer weten?