Welkom bij weer een nieuwe aflevering van Microsoft Knowledge Nuggets. Ik ben uw gastheer, Mirko Peters. Het onderwerp van vandaag is er een waar bijna iedereen van heeft gehoord, maar weinig een echt begrijpen, APIs. U heeft de term waarschijnlijk vaak voorbij horen komen. Het is een van die technische termen die mensen gebruiken als ze slim willen overkomen. Maar dit is het punt, APIs zijn eigenlijk heel simpel. Het is gewoon een manier voor software om met elkaar te communiceren. Uw telefoon vraagt data op bij een server. De server stuurt het terug. Dat is een API-aanroep. Stel u nu voordat u 20, 50 of 100 APIs heeft. Elke API gebruikt wellicht andere authenticatie, andere limieten en andere documentatie als die er al is. Plotseling verandert wat begon als een simpel gesprek tussen twee apps in een complete chaos. Zonder centraal beheer vindt elk team opnieuw het wiel uit. Het ene team bouwt een eigen authenticatiesysteem, het andere eigen logboekregistratie.

Overal ontstaan beveiligingslekken. Ontwikkelaars raken verward over welke API wat doet en u heeft geen enkel overzicht meer van wat er in uw systeem gebeurt. Azure API Management lost dit op. Het geeft u één centraal controlecentrum. Zie het als een verkeerstoren voor uw API. Aan het einde van deze aflevering begrijpt u wat het precies is, waarom het belangrijk is en hoe alles samenkomt. Pak uw koffie en laten we beginnen. Het probleem, teveel APIs, geen controle. Dit is de realiteit van moderne software. Tien jaar geleden had u waarschijnlijk één grote applicatie, een mannelied, één database, één API, simpel. Vandaag de dag is diezelfde applicatie wellicht opgedeeld in tientallen microservices. Elke service doet één ding, gebruikersaccounts, betalingen, voorraad, meldingen en elk stelt zijn eigen API bloot. Plotseling heeft u 10, 50 of 100 verschillende toegangspunten tot uw systeem. Stel u nu voor dat u een ontwikkelaar bent die iets bouwt met deze APIs.

U moet ze allemaal vinden en voor elk de authenticatie uitvogelen. Sommigen gebruiken API-sleutels, andere OAuth en sommigen helemaal niets. U moet limieten handmatig beheren of het risico lopen geblokkeerd te worden. U moet begrijpen welk dataformaat elke API verwacht. Het is uitputtend. En vanuit operationeel oogpunt wordt het alleen maar erger. Zonder centrale gateway moet elk team handmatig beveiliging en lagging toevoegen aan hun eigen service. Sommige teams doen dit goed, andere vergeten fouten te loggen. Sommigen valideren invoer helemaal niet. Inconsistent en foutgevoelig, een beveiligingsnachtmerrie die wacht om te gebeuren. Compliance wordt bijna onmogelijk. Moet u aantonen wie wat wanneer heeft geopend? Succes met het verzamelen van addedlugs uit 20 verschillende services, elk met een eigen logformaat. Wil je weten hoeveel API-aanmoepen je systeem voorregimaat heeft verwerkt? Je bent statistieken aan het samenvoegen vanuit een dozijn verschillende dashboards.

Hier is het punt. Naarmate je schaalt is dit niet alleen vervelend. Het loopt vast. Je kunt niet meer ontwikkelaars, services of klanten toevoegen zonder centraal controlepunt. Zie het als een gebouw. Stel je voor dat elke kamer een ander slot heeft. Er is geen receptie of wegwijzer. Bezoekers dwalen rond op zoek naar de juiste deur, raken gefrustreerd en geven het uiteindelijk op. Totale chaos. Dit is het probleem dat API-beheer moet oplossen. Wat is Azure API Management? De verkeerstoren. Dus, wat is Azure API Management precies? Hier is de simpelste definitie. Het is een beheerde service die tussen je back-end API's en de apps, websites, apparaten en partners die ze gebruiken in staat. Maar het punt is, het is niet zomaar een proxy. Een proxy stuurt verkeer door en dat is het. Azure API Management dekt de volledige levenscyclus van je API's. Publiceer, beveilig, monitor en beëindig ze uiteindelijk.

Het is een compleet controlecentrum. Laten we het opsplitsen in drie hoofdcomponenten. De eerste is de gateway. Dit is de voordeur. Elk inkomend verzoek van een app of website komt eerst bij de gateway aan, nooit direct bij je back-end. De gateway verwerkt het verzoek, blinkt je ingestelde beleid af, verzamelt statistieken en stuurt het dan door naar de juiste back-end service. Zie het als de verkeersregelaar. Vervolgens is er het beheervlak Management Plane. Hier definieer je alles. Je API's, je beleid, je producten, je abonnementen. Dit doe je via de Azure portal, de opdrachtregel of infrastructuur als code zoals Bicep of Terraform. Het is de controlekamer waar je configureert hoe alles werkt. En dan, de ontwikkelaarsportal. Dit is een self-service website waar ontwikkelaars, zowel intern als extern, je API's kunnen ontdekken, documentatie lezen, abonnementsleutels krijgen en zelfs API aanroepen direct in hun browser testen.

Geen heen en weer gemail met pdf'jes meer. Hier is een analogie die helpt. Denk aan een moderne luchthaven. De gateway is de landingsbaan. Elk vliegtuig landt daar eerst. Het beheervlak is de verkeerstoren. Het regelt het verkeer, stelt regels in en monitort alles. En de ontwikkelaarsportal is het informatiebord. Piloten checken dit voor vertrek en vinden alle informatie die ze nodig hebben zonder met iemand te praten. Laten we nu inzoomen op de gateway. Dat is het onderdeel waarmee je apps daadwerkelijk praten en waar de echte magie gebeurt. De gateway, de voordeur van je API's. Laten we het over de gateway hebben, want dit is het deel waar je apps echt contact mee maken. Elk verzoek van een mobiele app, website of IOT-apparaat komt eerst bij de gateway aan, nooit direct bij je back-end. Dat is precies het hele idee. De gateway staat vooraan en fungeert als een enkel toegangspunt. De gateway kan beleid toepassen voordat het verzoek wordt doorgestuurd.

Beleid bestaat uit regels in XML of JSON zoals rate limiting, IP filtering, header herschrijving en authenticatiechecks. En dat allemaal zonder één regel van je back-end code te wijzigen. Hier is een concreet voorbeeld. Stel, je hebt een gratis en een premium laag voor je API. Met beleid kun je gratis gebruikers beperken tot 5 verzoeken per minuut, terwijl premium gebruikers er 100 krijgen. Je back-end merkt hier niets van. Die verwerkt simpelweg de verzoeken. De gateway regelt de handhaving. De gateway regelt ook de caching. Als data herhaaldelijk wordt opgevraagd, zoals een productlijst die zelden verandert, kan de gateway het antwoord cachen en direct serveren. Je back-end hoeft niet lastig gevallen te worden, wat zorgt voor snellere antwoorden en minder serverbelasting. Het kan ook data transformeren. Je back-end geeft misschien XML terug, terwijl je mobiele app JSON verwacht. De gateway kan dit direct tijdens het proces converteren.

Je back-end hoeft niet te veranderen en je app ook niet. De gateway regelt de vertaling. En het logt elke aanroep, elk verzoek, elk antwoord en elke fout. Je krijgt een volledig addedspoor van wie wat opriep, wanneer en wat er gebeurde. Dat alleen al is de moeite waard voor compliance doeleinden. Als je een wereldwijd publiek hebt, kun je de gateway in meerdere regio's inzetten. Verkeer wordt automatisch naar de dichtstbijzijnde geleid, wat lagere latentie en een betere ervaring geeft. Nog iets, de gateway verbergt de echte URL van je back-end. Clients zien alleen het adres van de gateway. Je back-end servers blijven verborgen voor het internet. Dat is direct een enorme beveiligingswinst. Beleid, de motor die alles aanstuurt. Dus hoe zit het met dat beleid waar ik het over had? Het is de motor die API-M echt krachtig maakt. Beleid past het gedrag van verzoeken of antwoorden aan zonder dat je je back-end code hoeft aan te raken.

Zie het als een wrapper rond je API. Terwijl verkeer er doorheen stroomt, kan het automatisch zaken toevoegen, verwijderen of wijzigen. Beleid kan op vier momenten in de levenscyclus van een verzoek worden uitgevoerd. Inbound, op de weg naar binnen, voordat het verzoek je back-end bereikt. Outbound, op de weg terug, voordat het antwoord bij de client komt. Back-end, vlak voordat het verzoek je service bereikt. En bij fouten, wanneer er iets misgaat. Veel voorkomende inkomende acties zijn het valideren van JWT-tokens om de identiteit van de aanroeper te controleren, API-sleutels verifiëren, URL's herschrijven en beperken op IP-adres. Dit alles gebeurt voordat uw back-end ook maar één verzoek ontvangt. Voor uitgaand verkeer kunt u de response body transformeren, tekst zoeken en vervangen, gevoelige velden verwijderen, formaten wijzigen. U kunt antwoorden cachen zodat herhaalde verzoeken uw back-end niet belasten.

U kunt zelfs headers verwijderen die interne informatie lekken. Hier is een concreet voorbeeld. Stel dat uw API-productbeschrijvingen retourneert waar overal het woord blauw in staat. U wilt een rebrand doorvoeren en in plaats daarvan geel gebruiken. In plaats van uw back-end code aan te passen, voegt u één uitgaand beleid toe. Zoek blauw, vervang door geel. En klaar, uw back-end verandert nooit. Beleid voor rate limiting en quota beschermt uw back-end tegen misbruik. Als iemands app op hol slaat en uw API 10.000 keer per seconde bestookt, grijpt het beleid in en zegt, rustig aan. Uw back-end blijft gezond. Geavanceerde logica nodig? U kunt aangepaste C-Sharp expressies schrijven binnen beleidsregels. Deze worden gecompileerd voor prestaties. Er zijn dus geen runtime kosten. U kunt gebruikersrollen opzoeken, dynamische limieten berekenen of antwoorden voorwaardelijk transformeren op basis van request headers.

De belangrijkste conclusie is deze. Met beleidsregels kunt u het gedrag van uw APIs bepalen zonder de onderliggende code aan te raken. Dat betekent snellere wijzigingen, minder implementaties en minder risico. Producten en abonnementen, APIs verpakken voor consumenten. Nu uw APIs zijn gedefinieerd, beleid is ingesteld en de gateway soepel draait. Maar hoe geeft u verschillende klanten toegang tot verschillende zaken? Dat is waar producten en abonnementen om de hoek komen kijken. In API-M groepeert u APIs in iets dat een product wordt genoemd. Zie het als een bundel. U kunt een gratis product hebben dat alleen uw basis APIs bevat. Misschien alleen lezen toegang en daarnaast een premium product met alles inclusief schrijfbewerkingen en admin endpoints. Ontwikkelaars abonneren zich niet op individuele APIs, ze abonneren zich op een product. Wanneer ze zich abonneren, krijgen ze een abonnementsleutel.

Eigenlijk twee sleutels, zodat u er één kunt vernieuwen zonder downtime. Die sleutel is een toegangsbewijs om elke API in dat product te gebruiken. U bepaalt hoe abonnementen werken. Producten kunnen goedkeuring vereisen. U accepteert elke abonnee handmatig of ze kunnen openstaan voor zelfbediening. Iedereen kan zich aanmelden en krijgt direct toegang. U kunt ook juridische voorwaarden opnemen die gebruikers moeten accepteren voor ze zich abonneren. Dat is belangrijk als uw APIs gevoelige gegevens verwerken. Dit is hoe u APIs te gelden maakt. Een gratis product met lage limieten, 5 aanroepen per minuut. Een betaald product met hogere limieten of meer endpoints, 100 aanroepen per minuut, plus toegang tot premium functies. Uw backend merkt daar niets van. De Gateway twinkt limieten af op basis van het product waarop de aanroeper is geabonneerd. Hier is een praktijkvoorbeeld. Stel je voor dat je een conferentie-app bouwt.

Je maakt een deelnemersproduct met APIs voor het dagschema, sprekersbiografieën en een plattegrond. Daarnaast een sponsorproduct dat ook APIs voor leadgeneratie bevat. Sponsors kunnen badges van deelnemers scannen en contactgegevens ophalen. Dezelfde backend, verschillende producten, verschillende toegangsniveaus. Die twee abonnementsleutels zijn ontworpen voor roulatie. Als een sleutel gecompromitteerd raakt, genereer je een nieuwe. Met de tweede sleutel kun je overschakelen zonder de dienst te onderbreken. Genereer een nieuwe sleutel, update je app en trek de oude in. Naadloos. De ontwikkelaarsportal, self-service voor API-gebruikers. Dus, je hebt je API-producten ingesteld. Nu moeten ontwikkelaars ze kunnen vinden. Dat is de taak van de ontwikkelaarsportal. De ontwikkelaarsportal is een website die in elk API-m-exemplaar is ingebouwd. De ontwikkelaars gebruiken deze om je APIs te bekijken, documentatie te lezen en eindpunten interactief te testen in hun browser.

Geen installatie nodig en geen heen en weer gemail. Het punt is echter dat deze standaard niet gepubliceerd is. Wanneer je je API-m-exemplaar voor het eerst maakt, bestaat de portal, maar is deze voor niemand zichtbaar. Je moet hem eerst aanpassen en publiceren. Dat is bewust gedaan. Je wilt geen half afgewerkte portal aan de wereld tonen. Je kunt merkkleuren en logo's aanpassen en zelfs WordPress-inhoud voor een blog naast je API-documentatie insluiten. Het is volledig aanpasbaar aan de uitstraling van je bedrijf. De echte waarde is self-service. Ontwikkelaars melden zich aan, krijgen automatisch hun abonnementsleutels en kunnen direct APIs aanroepen. Geen handmatige e-mails, geen wachttijden voor goedkeuring, geen supporttickets met vragen over sleutels. Ze doen het zelf, wat je werklast voor ondersteuning aanzienlijk vermindert. Je kunt ook wijzigingslogs en release-opmerkingen publiceren.

Wanneer je een API bijwerkt, zien ontwikkelaars dit direct in de portal zonder verrassingen. Toegang kan openbaar zijn voor iedereen met de URL, of je kunt deze beperken tot gebruikers van je entra-ID-tenant, zodat alleen mensen binnen je organisatie kunnen browsen. Beide opties bestaan voor verschillende gebruikscenario's. De ontwikkelaarsportal maakt van je API-beheer een echt platform. Zie het als de etalage voor je APIs. Zonder deze portal moeten ontwikkelaars door documentatie zoeken en rondvragen. Met deze portal vinden ze wat ze nodig hebben en kunnen ze direct bouwen. Beveiliging, authenticatie, autorisatie en geheimen. Al deze kracht is nutteloos als de beveiliging niet op orde is. Laten we het dus hebben over hoe API-M identiteit, toegang en geheimen beheert. API-M ondersteunt meerdere authenticatie-methoden. De eenvoudigste zijn abonnementsleutels, waar we het eerder over hadden.

Maar voor productiesystemen wil je iets sterkers, zoals OAuth 2.0, JWT-tokens, client-certificaten of IP-filtering. Je brengt deze in lagen aan op basis van hoe gevoelig je API is. Voor productie is het gebruik van OAuth 2.0 met entra-ID the best practice. Zo werkt dat. De client-app krijgt een token van entra-ID en verstuurt dit bij de API-aanvraag. API-M valideert het token door de handtekening, uitgever, doelgroep en verloopdatum te controleren. Als het geldig is, stuurt API-M de aanvraag inclusief token door naar je backend. Je backend vertrouwt dit omdat API-M het al heeft gecontroleerd, dus je backend hoeft niet opnieuw te valideren. Dat is weer één ding minder dat elke service zelf moet afhandelen. Laten we het nu over geheimen hebben. API-sleutels, connection-strings en certificaten wil je niet hardcodet in beleidsbestanden of broncodebeheer hebben. API-M heeft een functie genaamd named values.

Je slaat geheimen centraal op in API-M en verwijst er in je beleid naar bijnaam. De werkelijke waarde verschijnt nooit in je beleidscode. Sterker nog, je kunt named values koppelen aan Azure Key Vault. De geheimen blijven versleuteld in Key Vault en API-M haalt ze op tijdens runtime. Niemand, zelfs je DevOps-team niet, ziet de werkelijke waarde van het geheim. Wanneer je een sleutel moet roteren, update je deze in Key Vault en API-M verwerkt de wijziging automatisch. API-M ondersteunt ook beheerde identiteiten. Hiermee kan API-M verifiëren bij andere Azure-services, zoals Key Vault of een back-end API, zonder inloggegevens op te slaan. Azure beheert de identiteit, dus jij hoeft alleen rechten toe te kennen. En voor netwerkisolatie kun je API-M binnen een virtueel netwerk implementeren. Dat is de premium laag. Of gebruik Azure Frontdoor. Het punt is dat je back-end services nooit direct aan het internet blootgesteld hoeven te worden.

API-M is het enige wat de buitenwereld ziet. Deze gelaagde aanpak bouwt een verdediging in de diepte op. Authenticatie bij de gateway, geheimen in een kluis, netwerkisolatie rondom je back-ends. Elke laag versterkt de volgende. Prijsniveaus, welke past bij jou? Dus, wat kost het? Laten we de niveaus doornemen. De verbruik laag, consumption tier. Betaal per API aanroep zonder vaste maandelijkse kosten. Perfect voor laag volume of piekbelastingen, zoals wanneer je aan het prototype bent. Als je nog niet zeker weet wat je nodig hebt, begin dan hier. De ontwikkelaarslaag, developer tier, geeft je vaste lage maandelijkse kosten van ongeveer 50 dollar. Volledige functieset, maar geen sla. Ideaal voor ontwikkel- en testomgevingen. Je krijgt alles wat premium heeft, maar je mag het niet gebruiken voor productie. De basislaag, basic tier, is het instapniveau voor productie. Lagere doorvoer, geen ondersteuning voor virtuele netwerken, maar je krijgt wel een echte sla.

Geschikt voor interne tools of kleine projecten waar privé-netwerken niet cruciaal zijn. De meeste bedrijven kiezen voor de standaardlaag. Inclusief ondersteuning voor virtuele netwerken, een sla van 99,95 procent en goede doorvoer. Als je bedrijfscritieke APIs draait, is dit waarschijnlijk waar je uitkomt. De premiumlaag is voor wereldwijde ondernemingen die maximale betrouwbaarheid en privé-netwerken nodig hebben. Multi-regio-implementatie, self-hosted gateway, sla van 99,99 procent, volledige virtuele netwerkinjectie. Begint bij ongeveer 2700 per maand per eenheid. Microsoft introduceerde ook V2-lagen Basic V2, Standard V2 en Premium V2. Zij vereenvoudigen de prijsstelling met inbegrepen aanvraagquota en kosten per miljoen overschrijdingen. In plaats van meerdere meters bij te houden, krijg je een duidelijk pakket aanvragen en betaal je voor extra gebruik in eenvoudige stappen. Zo maak je een keuze.

Begin met developer voor het testen. Stap over naar Standard voor productie. Kies premium als je wereldwijde schaal- of privé-netwerken nodig hebt. En vergeet niet, je kunt later altijd nog van laag wisselen. Begin klein een groei naarmate je behoefte veranderen. Dit hebben we behandeld. API-beheer brengt de chaos van vele APIs samen in één controlecentrum voor gateways, beleid, beveiliging en ontwikkelaarservaring. De belangrijkste lay is dat het meer is dan een proxy. Zie het als het brein- en het zenuwstelsel van je API-ecosysteem. Zonder dit bouwt elk team hun eigen authenticatie, logging en rate-limiting. Je eindigt met inconsistentie, beveiligingslekken en geen enkel overzicht van wat er gebeurt. Met dit beheer krijg je consistentie, beveiliging en schaalbaarheid zonder voor elke service het wiel opnieuw uit te vinden. Hier is een simpele oefening. Denk aan één API die je momenteel direct blootstelt.

Misschien een functie-at-point of een app-service. Hoe zou het plaatsen van API-beheer ervoor zorgen dat je beveiligingsniveau en monitoring veranderen? Alleen al door die oefening te overwegen, zul je de waarde inzien. Volgende stap, abonneer je op het kanaal. In toekomstige afleveringen laten we zien hoe je een API importeert, je eerste beleid toepast en gebruik in real-time monitort. Je gaat van theorie naar de praktijk. En als je dit nuttig vond, deel het dan met iemand die een app bouwt. Het bespaart hen maanden aan hoofdpijn. Bedankt voor het luisteren.