Het web bestaat uit uitbreidbare software die met elkaar verbindt door middel van API's (application programming interfaces). Door gebruik te maken van standaarden voor authenticatie, dataverzoeken en data-packaging, bieden API's bedrijven een manier om informatie te delen en verschillende systemen met elkaar te verbinden.
Maar niet alle API's zijn hetzelfde. In veel gevallen maken bedrijven of softwareontwikkelaars achteraf nog even API-toegang mogelijk, met het idee dat API-toegang niet anders is dan toegang tot websites. Het loopt namelijk allemaal via HTTP, dus hoe ingewikkeld kan het zijn?
Een dergelijke aanpak, waarin onvoldoende aandacht wordt besteed aan de systeemspecifieke architectuur, security en robuustheid, kan serieuze problemen veroorzaken voor aangesloten systemen en, uiteindelijk, gebruikers en klanten die afhankelijk zijn van API-toegang. Wat gebeurt er bijvoorbeeld wanneer de gegevensuitvoer van een API corrupt is? Wat gebeurt er als API-oproepen en -functionaliteit slecht worden gedocumenteerd? En wat gebeurt er wanneer er een datalek ontstaat, omdat een van de tientallen oproepen niet in een afgeschermde omgeving plaatsvond?
Dit kan allemaal leiden tot het uitvallen van systemen: gegevens komen niet door, de inkomstenstroom stopt, en, nog erger, de kans op een lek groeit exponentieel. Deze situatie wordt nog problematischer als er kosten zijn verbonden aan het gebruik van de API. In deze gevallen heeft de API vaak specifieke SLA's die bij schending leiden tot inkomstenverlies. Als het ontwerp van een API slecht is, is het moeilijk om constant op hoog niveau te presteren op parameters als rate limit of transactionele round-trip tijden.
Daarnaast houdt een goed ontwerp niet alleen rekening met de API zelf, maar ook met alle onderliggende microservices en systemen waar een API mee samenwerkt, zoals een database. Als er geen rekening wordt gehouden met de beperkingen van deze andere systemen, kan zelfs de best ontworpen en geprogrammeerde API niet voldoen aan de verwachtingen.
Dus hoe kun je garanderen dat jouw API niet het slachtoffer wordt van een laks ontwerp? Allereerst door te erkennen dat API-verkeer iets anders is dan traditioneel webverkeer. Elke API-oproep kan een 'read' of een 'write' zijn. Deze hebben verschillende HTTP-methoden en behandelen URI's (uniform resource identifiers) anders.
Elke API-call van een client staat op zichzelf, dus ze gebruiken geen bekende technieken om verkeer te versnellen, zoals HTTP keepalives, persistent SSL- of authenticatiesessies. Wanneer je de verschillen tussen API en normaal webverkeer begrijpt en respecteert, helpt het je realiseren welke verschillende effecten API's kunnen hebben op de bestaande applicatieomgeving en infrastructuur. Wanneer je de verschillen tussen API's en de rest van je applicaties begrijpt (ondanks dat ze misschien wel in dezelfde taal zijn geschreven), moet je de volgende drie stappen volgen om ervoor te zorgen dat jouw API-aanpak succesvol wordt.
1. Maak impact op systemen inzichtelijk
De eerste stap is het beoordelen van de impact. Voordat je iets gaat programmeren, moet je ervoor zorgen dat in je ontwerp is nagedacht over de samenwerking van de API met aangesloten systemen en software. Als de API na het ophalen van data uit meerdere bronnen een taak uitvoert, welke impact hebben de voorspelde 'concurrent user requests' dan op die systemen? Kan de API een intensieve taak op de CPU laten draaien?
Denk bijvoorbeeld aan een vluchtroute-API van een luchtvaartmaatschappij. Zo'n API kan uit de lucht worden gehaald door een aanvaller die op zoek gaat naar de goedkoopste route van A tot Z met 24 overstappen. Dit is vooral belangrijk als deze systemen, zoals een database, worden gebruikt door andere applicaties. En hoe zit het met beveiliging? Moet API-authenticatie worden beheerd door een bestaand beveiligingssysteem (zoals een LDAP-server) of moet er iets nieuws worden geïmplementeerd (zoals een oAuth-server)?
Al deze keuzes moeten duidelijk worden vastgelegd, samen met een oplossing voor mogelijke failovers. Door alles te documenteren, krijgen programmeurs een duidelijk beeld van de manier waarop de API moet worden gemaakt en hoe load balancers, caches, API-gateways en applicatiecode het meest effectief kunnen worden gebruikt. Zo kan de API aan alle vereisten voldoen.
2. Stel de impact op de organisatie vast
De tweede stap tijdens het bouwen en lanceren van de API is het vaststellen van de impact voor de organisatie. Welk teams gaan de API ontwerpen, programmeren, implementeren, onderhouden en ondersteunen?
Een voorbeeld: de organisatie hanteert een beleid waarbij al het verkeer als multi-tenant load balancer wordt verwerkt, maar het API-team heeft controle over de softwareregels nodig om configuratiewijzigingen te kunnen doorvoeren. Er kan een aanzienlijke vertraging of storing van de API-bewerking optreden als het team moet wachten op een gecentraliseerde functionaliteit om deze wijzigingen aan te brengen.
Wanneer je besluit om API's te implementeren, kan het dus zo zijn dat je infrastructuur om een nieuwe aanpak vraagt. In plaats van een single application gateway, heeft je organisatie misschien wel meerdere tiers nodig. Allereerst een tier 1- netwerk met een basisset van regels met daaronder een tier 2-netwerk met meer geavanceerde regels waar het API-ontwikkelingsteam directe toegang tot heeft.
3. Ontwikkel onderhoudsplan voor de lange termijn
De laatste stap is de ontwikkeling van een duidelijk onderhoudsplan voor de lange termijn. Als API's reactief worden ingezet (bijvoorbeeld wanneer een partner of klant toegang tot back-end systemen wilt), is er vaak geen idee hoe deze op lange termijn moeten worden onderhouden. Ondersteunende systemen, zoals databases en besturingssystemen, kunnen in de loop van de tijd veranderen of worden geüpdatet.
Maar zullen dergelijke updates de API-functies beïnvloeden? Of misschien nog wel belangrijker: bieden nieuwe systeemversies kansen voor betere API-prestaties of nieuwe functies? De enige manier om die nieuwe voordelen te realiseren, is dat een team eigenaar wordt van de levenscyclus van de API.
Wanneer dat gebeurt, kunnen teams plannen om elke API op regelmatige basis te beoordelen. Het is een soort APK-keuring, maar dan voor je API. Een moment om goed onder de motorkap te kijken, de bandenspanning te controleren en alle elektronische systemen na te lopen zodat de auto soepel kan blijven rijden. Wanneer een team 'ownership' heeft over de hele levenscyclus van een API, kan het ook rekening houden met de afschrijving.
Natuurlijk wil niemand praten over het uitschakelen van een API wanneer je er zelf hard aan hebt gewerkt, maar het kan nodig zijn om op enig moment een API te schrappen. Begrijpen wat nodig is om een API te schrappen, is van cruciaal belang om alle gebruikers van die API geruisloos naar andere interfaces te verplaatsen zonder dat ze belangrijke functies gaan missen.
Zelfs als je deze drie stappen volgt, is het belangrijk om te begrijpen dat er geen standaardaanpak is voor de ontwikkeling van API's. Sommige organisaties zullen hun API's ontwikkelen door een gecentraliseerd team in dienst te nemen, terwijl andere organisaties de API-ontwikkeling onder kleine teams zullen onderverdelen.
Sommige infrastructuurteams willen een enkele, grote 'application gateway' om al het API-verkeer in te beheren, terwijl andere teams voorkeur hebben voor individuele micro-gateways voor elke losse API. Hoe je ook besluit om je API's te benaderen, houd er rekening mee dat een goed ontwerp, zicht op de impact binnen de organisatie en het waarborgen van 'ownership' van de levenscyclus ervoor zorgen dat de API's niet alleen kunnen worden gebruikt, maar ook flexibel genoeg zijn voor toekomstige versies.
Owen Garrett is verantwoordelijk voor de product- en go-to-marketstrategie voor de web acceleration en delivery-oplossingen van NGINX. Owen heeft meer dan 15 jaar ervaring in software engineering en productmanagement bij onder meer Riverbed. Tegenwoordig gebruikt Owen zijn technische en managementexpertise voor het verbeteren van de producten en klanttevredenheid van NGINX.
-
-
Er zijn nog geen reacties.Reageer
Preview