REST API is een uitstekende oplossing om twee of meerdere applicaties met elkaar te verbinden. Maar soms grijpen we te snel naar een API om data uit te wisselen en systemen met elkaar te integreren. We hebben daarom een top vier van valkuilen voor je op een rij gezet, zodat je uiteindelijk een weloverwogen keuze kunt maken voor het bouwen van een REST API.
1. Reliability in messaging vergeten
Wat we hiermee bedoelen, is dat een verzoek maar één keer (exactly once) wordt uitgevoerd. Sommige acties (verbs) van REST API zijn idempotent, wat betekent dat het resultaat van een succesvolle aanvraag onafhankelijk is van het aantal keer dat het is uitgevoerd. De vraag is: kan een specifieke backend-applicatie duplicates vermijden? Met een integratielaag heb je dan de mogelijkheid om alsnog een proces te creëren dat bestaat uit een betrouwbare keten van acties.
Stel, we hebben een REST API om documenten te archiveren, maar het achterliggende archief is niet zo geschikt om met duplicates om te gaan. Het is dan belangrijk om de afnemer van de API niet te belasten met de manco’s van de backend-applicatie. De afnemer moet simpelweg het bericht opnieuw kunnen verzenden, zelfs als er geen fout is teruggegeven. Om dat te kunnen doen, is het van groot belang dat berichten uniek herkenbaar zijn. De integratielaag is dé plek om manco’s van de backend-applicaties op te vangen. In het geval van de archiefoplossing worden alle unieke berichtidentificaties opgeslagen. Komt een bericht voor de tweede keer binnen op de integratielaag? Dan wordt eerst in het archief gezocht of het document al bestaat. Zo niet, dan wordt het document alsnog aangemaakt en de afnemer van de API krijgt netjes een HTTP 200 OK terug.
2. Een ‘one API fits all’ bouwen
Creëer verschillende REST API’s voor de behoeften van een specifieke gebruiker of afnemer. Het is niet ongebruikelijk om voor een objectenmodel meerdere API’s te hebben. Een API tussen applicaties communiceert namelijk op een andere manier (geautomatiseerd) dan een API tussen een applicatie en eindgebruiker. De eindgebruiker kan bijvoorbeeld zelf bepalen welke actie hij of zij onderneemt bij een foutmelding. Uiteraard werkt een eindgebruiker niet direct met een API, maar doet hij of zij dit via een portal of app.
Daarnaast is er een verschil in rechten: je wilt niet dat dezelfde informatie beschikbaar is voor de eindgebruiker dan bij een REST API tussen applicaties. Voor de ene gebruiker is een e-mailadres wel relevant, maar voor de ander niet. Je kunt wel hetzelfde objectenmodel aan de achterkant laten staan, alleen aan de voorkant filter je gegevens op basis van de bestaande API’s. Probeer wel te voorkomen dat je voor elke afnemer een point-to-point API maakt, anders dijt het aantal REST API’s te veel uit.
3. Geen inzicht hebben in fouten die terugkomen
Wanneer een aanvraag erg lang duurt of misgaat, wil je als beheerder weten waar de bottleneck zit. Door een integratielaag in te richten, krijg je inzicht in wat er precies fout gaat. Bijvoorbeeld voor het aanmaken van een klant (via een REST API tussen applicaties), controleer je in de integratielaag op duplicates. Als beheerder zie je de berichten die zijn langsgekomen, maar ook inhoudelijke informatie over foutmeldingen. Geef de fouten ook terug aan een eindgebruiker, zodat hij of zij hierop kan handelen. Correleer deze foutmeldingen met die in je beheerlaag, zodat je de oorzaak kunt terugvinden en de actie alsnog voltooien.
-
4. Een REST API is niet de oplossing voor elk probleem
Met het gebruik van REST API’s ontstaat een vorm van simplificatie: de verantwoordelijkheden beleg je ergens anders, bijvoorbeeld in een integratielaag. Soms is die simplificatie prima, je wilt bijvoorbeeld het inloggen op een bankapplicatie of klantportaal zo gemakkelijk mogelijk maken voor een gebruiker. Maar bij verwerking in batches of bij events zijn acties lastig te orkestreren met een API.
Denk bijvoorbeeld aan een jaarlijks pensioenoverzicht. Die wordt in batches verstuurd, wat prima gaat met een REST API. Maar ga je daar afhankelijkheden inbouwen, zoals een uitbetaling waarbij ook het banksaldo moet worden aangepast, dan wordt deze actie een stuk complexer. Je kunt deze complexiteit dan beter herbeleggen in een integratielaag.
HEB JIJ EEN INTEGRATIE VRAAGSTUK OF EEN VRAAG?
Wil je meer weten over hoe je een goede REST API definieert en veelvoorkomende valkuilen vermijdt? Bekijk dan onze video of neem contact met ons op. We helpen je graag verder met het goed inrichten van API’s. Onze experts zijn op dit moment druk bezig, maar je kunt je vraag hier achterlaten of een moment inplannen om te chatten.
