API’s en API Management

“Software is eating the world” zei iemand die veel slimmer is dan ik, nu ongeveer alweer 10 jaar geleden… Tijdens de corona crisis werden veel bedrijven nogmaals met de neus op de feiten geduwd en beseffen ze maar al te goed dat er nog meer moet worden ingezet op het digitaliseren van hun huidige diensten. Dus CIO’s, IT-managers, etc. overal krijgen dan ook de opdracht om nog sneller werk te maken van het digitaliseren, moderniseren en innoveren van allerlei processen en applicaties. Maar vaak staan daar een aantal olifanten in de kamer. Logge, oldschool applicaties die al jaren processen ondersteunen, die misschien niet meteen super sexy zijn maar wel nog ‘werken’. Vooral interne gebruikers die er al jaren mee werken zien de gebreken niet meer en zijn ‘tevreden’ over de applicaties. Lees: ze hebben het opgegeven om de issues die ze ervaren door te geven. Nieuwe interne gebruikers stribbelen nog wat tegen in het begin en zullen eerst nog wel een poging doen. In het beste geval volgen ze dan gedwee en gebruiken ze de applicatie zonder verder te morren. In het slechtste geval haken ze af.

Applicatie innovatie, digitale transformatie en andere mooie termen worden nu aangereikt als dé oplossing voor die olifanten in de kamer. Gemakkelijker gezegd dan gedaan natuurlijk. Hoe begin je eraan en welke componenten zijn relevant in deze transitie. In deze blog wil ik graag één component eruit nemen die zeker op de roadmap moet staan: API’s en het daaraan gerelateerde API-management. API’s zijn een van de belangrijkste bouwstenen die je kunnen helpen bij applicatie innovatie. Door te beginnen met bepaalde data of zelfs functionaliteiten van bestaande applicaties beschikbaar te maken voor andere applicaties, kan dit op zijn beurt leiden tot een aanpak om de oude olifanten stilletjes uit te faseren. Zoals bij alle IT-componenten is ook bij API’s, governance van groot belang. API-management tools zijn hier het antwoord.

Wat is API-management?

Een lans breken voor het gebruik van API’s is anno 2020 niet meer nodig, denk ik. Maar toch, voor die enkelen die nog een kleine push nodig hebben, verwijs ik even naar het Amazon API mandaat van Jef Bezos, die zijn online boekenwinkeltje omvormde tot een succesvolle technology driven onderneming. Kort samengevat komt het erop neer dat ieder team binnen Amazon moet communiceren via API’s. Degenen die dit niet doen worden ontslagen. Een verwijzing naar het bijzondere mandaat vind je hier. Deze strategie heeft geleid tot het AWS (Amazon Web Services) dat we nu kennen. Een applicatie landschap volledig gebaseerd op API’s.

Het managen van deze API’s (documentatie, versioning, authenticatie, throttling, etc.…) zal bij AWS wel een hele kluif zijn (om even een understatement te gebruiken).De grootte van AWS en het aantal API’s dat zij gebruiken zal vele male groter zijn dan gemiddelde onderneming, maar de problematiek is voor iedereen relevant. Hoe zorg je ervoor dat de API’s alleen gebruikt worden door de applicaties die je wilt? Hoe krijg en behoud je zicht op het gebruik ervan, hoe weten ontwikkelaars hoe ze de API moeten gebruiken? Op deze vragen kan een API-management tool antwoord bieden. Een API-management tool bestaat dan ook typisch uit volgend elementen:

• API-gateway

  De gateway is de kern van het API-management. Het zorgt voor het exposen van de API’s en de routering van de API’s naar de backend systemen. Deze component zorgt onder meer voor het beveiligen van de API’s (zoals het gebruik van tokens, certificaten, etc.), het beperken van het gebruik van de API’s door rate limiting toe te passen, het loggen van alle metadata en het voorziet eventueel caching voor veelgebruikte services. Bij de meeste gateways is er ook een mogelijkheid om in minder of meerdere mate transformaties te voorzien tussen de API die wordt exposed en de interne services. Bijvoorbeeld om een json request om te zetten naar een XML formaat.

• Management portal

  De administratie van de API’s gebeurt in een management portal. In dit portaal worden verschillende API’s beheerd. Het is hier waar je verschillende API’s kan groeperen in logische blokken. Deze logische blokken kunnen dan op hun eigen manier worden gemanaged. Het beheer van deze blokken komt dan neer op het instellen en toepassen van policies. Een policy is een soort van regel die je wilt toepassen zodra een API wordt aangeroepen. Zo kan je verschillende policies na elkaar laten uitvoeren. Bijvoorbeeld, eerst een check of de client applicatie niet over zijn rate limit zit (meestal uitgedrukt in calls per seconde) en dan een transformatie van Json naar XML om vervolgens de backend service aan te roepen. In dit portaal vind je ook alle informatie omtrent het gebruik van de API en kan je de logs bekijken.

• Developer portal

  Misschien wel een van de features waarvan het belang en nut wordt onderschat is het developer portal. Het development portaal is het startpunt voor iedereen die je API’s wil gebruiken. Documentatie over de authenticatie, de API’s zelf en andere zaken om ervoor te zorgen dat ontwikkelaars aan de slag kunnen met je API. Op dit portaal kunnen ontwikkelaars zelf een applicatie registreren die de API kan gebruiken. Eventueel kan je een betalingscomponent toevoegen als je de API achter een betaalmuur wilt plaatsen. Zo een portaal is handig voor externe ontwikkelaars, maar ook voor intern gebruik heeft het zijn nut. Zeker als je verschillende teams hebt, kan de portal een handige tool zijn om ervoor te zorgen dat iedereen weet wat er beschikbaar is aan API’s en hoe ze te gebruiken om zo de juiste APIX (API Experience) te creëren.

Waarom is het (nu nog niet) nodig?

De vraag “heb ik een API-management applicatie nodig?” lijkt heel hard op de vraag “to ESB or not to ESB”. Ross Mason stelde een lijstje op om te bepalen wanneer je een ESB zou willen gebruiken en wanneer niet. Een aantal punten op die lijst zijn ook van toepassing bij de vraag of je een API management applicatie nodig hebt of niet. De vragen die je moet stellen zijn: Hoeveel applicaties zullen mijn API’s gaan gebruiken? Heb ik een compleet beeld over wie mijn API’s nu al gebruikt? Heb ik zicht op hoe vaak deze worden gebruikt? Weet ik welke API’s er binnen mijn onderneming beschikbaar zijn?

Als je op deze vragen niet kan antwoorden, dan is het misschien interessant om te kijken naar een API-management oplossing. Maar eerder misschien ook niet. Als je een kleine set van API’s hebt, perfect gedocumenteerd en maar een handvol client applicaties die je zelf onder controle hebt, dan kan je zeker verder zonder. Een API-management oplossing heb je niet nodig vanaf dag 1. Begin klein door ervoor te zorgen dat je klaar bent voor de stap te nemen naar een API-management oplossing. Je kan bijvoorbeeld de Open API spec gebruiken en embedden in de code. De Open API spec kan je dan gemakkelijk in een eigen portaal laten zien (of via een applicatie zoals swagger UI) en je kan er je eigen documentatie bij zetten. Eens de nood er is kan je die later importeren in een API-management tool. Ook belangrijk is dat je van in het begin guidelines hanteert omtrent versioning van de API’s, authenticatie, errorhanding, etc. Iets wat je ook gaat nodig hebben bij de overgang naar een API management oplossing. Denk aan de taxonomie. Een van de vervelendste zaken is het definiëren van objecten in een API. Van in het begin is het belangrijk om samen met domain experts te definiëren hoe het domein model van je business in elkaar zit. Zo een domein model vertaalt zich dan naar een model dat definieert hoe bijvoorbeeld een customer object er uit ziet. Door up front hier over na te denken ga je op termijn miserie besparen doordat iedereen dezelfde taal spreekt en bijgevolg er ook minder vertalingen en transformaties nodig zijn. 

Conclusie

Een API management oplossing is niet in elk IT-landschap van in het begin nodig. Wel is het belangrijk dat je het op de roadmap houdt en dat je van in het begin goed nadenkt over je API-strategie. Je kan alvast zelf een aantal oplossingen bekijken (bijvoorbeeld Azure API management) om een beter beeld te krijgen van wat zo een applicatie kan betekenen en waar je nu al op kan letten om in een latere fase de API-management tool makkelijk te kunnen inschuiven in je landschap.

In het kader van applicatie innovatie zijn API’s een van die fundamenten die je best meteen zo goed mogelijk inricht. Mocht je vragen hierover hebben, laat gerust iets weten.