WEBVTT 00:00:00.100 --> 00:00:02.520 Welkom bij weer een nieuwe aflevering van Microsoft Knowledge Nuggets. 00:00:02.680 --> 00:00:04.200 Ik ben uw gastheer, Mirko Peters. 00:00:04.420 --> 00:00:08.400 Het onderwerp van vandaag is er een waar bijna iedereen van heeft gehoord, maar weinig een echt begrijpen, APIs. 00:00:08.680 --> 00:00:10.820 U heeft de term waarschijnlijk vaak voorbij horen komen. 00:00:11.060 --> 00:00:14.600 Het is een van die technische termen die mensen gebruiken als ze slim willen overkomen. 00:00:14.820 --> 00:00:17.060 Maar dit is het punt, APIs zijn eigenlijk heel simpel. 00:00:17.260 --> 00:00:19.800 Het is gewoon een manier voor software om met elkaar te communiceren. 00:00:20.000 --> 00:00:21.680 Uw telefoon vraagt data op bij een server. 00:00:21.900 --> 00:00:23.000 De server stuurt het terug. 00:00:23.220 --> 00:00:24.420 Dat is een API-aanroep. 00:00:24.600 --> 00:00:26.940 Stel u nu voordat u 20, 50 of 100 APIs heeft. 00:00:26.940 --> 00:00:31.980 Elke API gebruikt wellicht andere authenticatie, andere limieten en andere documentatie als die er al is. 00:00:32.120 --> 00:00:36.100 Plotseling verandert wat begon als een simpel gesprek tussen twee apps in een complete chaos. 00:00:36.380 --> 00:00:38.960 Zonder centraal beheer vindt elk team opnieuw het wiel uit. 00:00:39.180 --> 00:00:42.940 Het ene team bouwt een eigen authenticatiesysteem, het andere eigen logboekregistratie. 00:00:43.120 --> 00:00:44.820 Overal ontstaan beveiligingslekken. 00:00:45.120 --> 00:00:50.340 Ontwikkelaars raken verward over welke API wat doet en u heeft geen enkel overzicht meer van wat er in uw systeem gebeurt. 00:00:50.520 --> 00:00:52.360 Azure API Management lost dit op. 00:00:52.520 --> 00:00:54.680 Het geeft u één centraal controlecentrum. 00:00:54.680 --> 00:00:56.920 Zie het als een verkeerstoren voor uw API. 00:00:57.300 --> 00:01:03.420 Aan het einde van deze aflevering begrijpt u wat het precies is, waarom het belangrijk is en hoe alles samenkomt. 00:01:03.720 --> 00:01:05.260 Pak uw koffie en laten we beginnen. 00:01:05.760 --> 00:01:08.120 Het probleem, teveel APIs, geen controle. 00:01:08.440 --> 00:01:10.360 Dit is de realiteit van moderne software. 00:01:10.620 --> 00:01:15.960 Tien jaar geleden had u waarschijnlijk één grote applicatie, een mannelied, één database, één API, simpel. 00:01:16.200 --> 00:01:19.960 Vandaag de dag is diezelfde applicatie wellicht opgedeeld in tientallen microservices. 00:01:19.960 --> 00:01:25.860 Elke service doet één ding, gebruikersaccounts, betalingen, voorraad, meldingen en elk stelt zijn eigen API bloot. 00:01:25.860 --> 00:01:29.420 Plotseling heeft u 10, 50 of 100 verschillende toegangspunten tot uw systeem. 00:01:29.620 --> 00:01:32.400 Stel u nu voor dat u een ontwikkelaar bent die iets bouwt met deze APIs. 00:01:32.680 --> 00:01:35.500 U moet ze allemaal vinden en voor elk de authenticatie uitvogelen. 00:01:35.740 --> 00:01:38.880 Sommigen gebruiken API-sleutels, andere OAuth en sommigen helemaal niets. 00:01:39.040 --> 00:01:41.780 U moet limieten handmatig beheren of het risico lopen geblokkeerd te worden. 00:01:41.960 --> 00:01:44.400 U moet begrijpen welk dataformaat elke API verwacht. 00:01:44.540 --> 00:01:45.480 Het is uitputtend. 00:01:45.480 --> 00:01:47.860 En vanuit operationeel oogpunt wordt het alleen maar erger. 00:01:48.060 --> 00:01:51.720 Zonder centrale gateway moet elk team handmatig beveiliging en lagging toevoegen aan hun eigen service. 00:01:52.000 --> 00:01:54.400 Sommige teams doen dit goed, andere vergeten fouten te loggen. 00:01:54.600 --> 00:01:56.220 Sommigen valideren invoer helemaal niet. 00:01:56.600 --> 00:01:59.700 Inconsistent en foutgevoelig, een beveiligingsnachtmerrie die wacht om te gebeuren. 00:01:59.980 --> 00:02:01.480 Compliance wordt bijna onmogelijk. 00:02:01.700 --> 00:02:03.440 Moet u aantonen wie wat wanneer heeft geopend? 00:02:03.680 --> 00:02:07.740 Succes met het verzamelen van addedlugs uit 20 verschillende services, elk met een eigen logformaat. 00:02:07.920 --> 00:02:10.800 Wil je weten hoeveel API-aanmoepen je systeem voorregimaat heeft verwerkt? 00:02:10.800 --> 00:02:13.900 Je bent statistieken aan het samenvoegen vanuit een dozijn verschillende dashboards. 00:02:14.080 --> 00:02:14.840 Hier is het punt. 00:02:15.060 --> 00:02:17.000 Naarmate je schaalt is dit niet alleen vervelend. 00:02:17.160 --> 00:02:17.900 Het loopt vast. 00:02:18.100 --> 00:02:21.500 Je kunt niet meer ontwikkelaars, services of klanten toevoegen zonder centraal controlepunt. 00:02:21.700 --> 00:02:22.600 Zie het als een gebouw. 00:02:22.780 --> 00:02:24.680 Stel je voor dat elke kamer een ander slot heeft. 00:02:24.860 --> 00:02:26.500 Er is geen receptie of wegwijzer. 00:02:26.760 --> 00:02:31.160 Bezoekers dwalen rond op zoek naar de juiste deur, raken gefrustreerd en geven het uiteindelijk op. 00:02:31.300 --> 00:02:32.220 Totale chaos. 00:02:32.540 --> 00:02:34.980 Dit is het probleem dat API-beheer moet oplossen. 00:02:35.260 --> 00:02:36.740 Wat is Azure API Management? 00:02:37.040 --> 00:02:38.040 De verkeerstoren. 00:02:38.300 --> 00:02:40.460 Dus, wat is Azure API Management precies? 00:02:40.460 --> 00:02:42.280 Hier is de simpelste definitie. 00:02:42.480 --> 00:02:48.020 Het is een beheerde service die tussen je back-end API's en de apps, websites, apparaten en partners die ze gebruiken in staat. 00:02:48.220 --> 00:02:50.160 Maar het punt is, het is niet zomaar een proxy. 00:02:50.380 --> 00:02:52.220 Een proxy stuurt verkeer door en dat is het. 00:02:52.360 --> 00:02:55.360 Azure API Management dekt de volledige levenscyclus van je API's. 00:02:55.680 --> 00:02:58.200 Publiceer, beveilig, monitor en beëindig ze uiteindelijk. 00:02:58.320 --> 00:02:59.780 Het is een compleet controlecentrum. 00:03:00.020 --> 00:03:01.900 Laten we het opsplitsen in drie hoofdcomponenten. 00:03:02.020 --> 00:03:03.040 De eerste is de gateway. 00:03:03.360 --> 00:03:04.160 Dit is de voordeur. 00:03:04.380 --> 00:03:08.440 Elk inkomend verzoek van een app of website komt eerst bij de gateway aan, nooit direct bij je back-end. 00:03:08.440 --> 00:03:14.320 De gateway verwerkt het verzoek, blinkt je ingestelde beleid af, verzamelt statistieken en stuurt het dan door naar de juiste back-end service. 00:03:14.600 --> 00:03:16.060 Zie het als de verkeersregelaar. 00:03:16.300 --> 00:03:18.320 Vervolgens is er het beheervlak Management Plane. 00:03:18.500 --> 00:03:19.720 Hier definieer je alles. 00:03:19.940 --> 00:03:22.860 Je API's, je beleid, je producten, je abonnementen. 00:03:23.040 --> 00:03:27.900 Dit doe je via de Azure portal, de opdrachtregel of infrastructuur als code zoals Bicep of Terraform. 00:03:28.120 --> 00:03:30.800 Het is de controlekamer waar je configureert hoe alles werkt. 00:03:30.940 --> 00:03:32.560 En dan, de ontwikkelaarsportal. 00:03:32.560 --> 00:03:41.280 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. 00:03:41.440 --> 00:03:43.300 Geen heen en weer gemail met pdf'jes meer. 00:03:43.480 --> 00:03:44.780 Hier is een analogie die helpt. 00:03:45.000 --> 00:03:46.260 Denk aan een moderne luchthaven. 00:03:46.480 --> 00:03:47.800 De gateway is de landingsbaan. 00:03:47.980 --> 00:03:49.380 Elk vliegtuig landt daar eerst. 00:03:49.560 --> 00:03:51.180 Het beheervlak is de verkeerstoren. 00:03:51.380 --> 00:03:54.120 Het regelt het verkeer, stelt regels in en monitort alles. 00:03:54.320 --> 00:03:56.580 En de ontwikkelaarsportal is het informatiebord. 00:03:56.760 --> 00:04:00.740 Piloten checken dit voor vertrek en vinden alle informatie die ze nodig hebben zonder met iemand te praten. 00:04:00.740 --> 00:04:02.500 Laten we nu inzoomen op de gateway. 00:04:02.720 --> 00:04:06.460 Dat is het onderdeel waarmee je apps daadwerkelijk praten en waar de echte magie gebeurt. 00:04:06.860 --> 00:04:08.920 De gateway, de voordeur van je API's. 00:04:09.120 --> 00:04:12.820 Laten we het over de gateway hebben, want dit is het deel waar je apps echt contact mee maken. 00:04:13.040 --> 00:04:18.180 Elk verzoek van een mobiele app, website of IOT-apparaat komt eerst bij de gateway aan, nooit direct bij je back-end. 00:04:18.400 --> 00:04:19.680 Dat is precies het hele idee. 00:04:19.940 --> 00:04:22.560 De gateway staat vooraan en fungeert als een enkel toegangspunt. 00:04:22.760 --> 00:04:25.600 De gateway kan beleid toepassen voordat het verzoek wordt doorgestuurd. 00:04:25.600 --> 00:04:31.880 Beleid bestaat uit regels in XML of JSON zoals rate limiting, IP filtering, header herschrijving en authenticatiechecks. 00:04:32.060 --> 00:04:34.780 En dat allemaal zonder één regel van je back-end code te wijzigen. 00:04:34.960 --> 00:04:36.240 Hier is een concreet voorbeeld. 00:04:36.520 --> 00:04:39.100 Stel, je hebt een gratis en een premium laag voor je API. 00:04:39.360 --> 00:04:43.880 Met beleid kun je gratis gebruikers beperken tot 5 verzoeken per minuut, terwijl premium gebruikers er 100 krijgen. 00:04:44.080 --> 00:04:45.480 Je back-end merkt hier niets van. 00:04:45.680 --> 00:04:47.220 Die verwerkt simpelweg de verzoeken. 00:04:47.440 --> 00:04:48.920 De gateway regelt de handhaving. 00:04:49.160 --> 00:04:50.720 De gateway regelt ook de caching. 00:04:50.720 --> 00:04:57.580 Als data herhaaldelijk wordt opgevraagd, zoals een productlijst die zelden verandert, kan de gateway het antwoord cachen en direct serveren. 00:04:57.720 --> 00:05:02.140 Je back-end hoeft niet lastig gevallen te worden, wat zorgt voor snellere antwoorden en minder serverbelasting. 00:05:02.340 --> 00:05:03.960 Het kan ook data transformeren. 00:05:04.160 --> 00:05:07.400 Je back-end geeft misschien XML terug, terwijl je mobiele app JSON verwacht. 00:05:07.600 --> 00:05:10.020 De gateway kan dit direct tijdens het proces converteren. 00:05:10.180 --> 00:05:12.460 Je back-end hoeft niet te veranderen en je app ook niet. 00:05:12.640 --> 00:05:14.260 De gateway regelt de vertaling. 00:05:14.480 --> 00:05:17.920 En het logt elke aanroep, elk verzoek, elk antwoord en elke fout. 00:05:17.920 --> 00:05:21.580 Je krijgt een volledig addedspoor van wie wat opriep, wanneer en wat er gebeurde. 00:05:21.760 --> 00:05:24.140 Dat alleen al is de moeite waard voor compliance doeleinden. 00:05:24.360 --> 00:05:27.900 Als je een wereldwijd publiek hebt, kun je de gateway in meerdere regio's inzetten. 00:05:28.100 --> 00:05:33.040 Verkeer wordt automatisch naar de dichtstbijzijnde geleid, wat lagere latentie en een betere ervaring geeft. 00:05:33.240 --> 00:05:35.860 Nog iets, de gateway verbergt de echte URL van je back-end. 00:05:36.060 --> 00:05:37.860 Clients zien alleen het adres van de gateway. 00:05:38.120 --> 00:05:40.260 Je back-end servers blijven verborgen voor het internet. 00:05:40.540 --> 00:05:42.720 Dat is direct een enorme beveiligingswinst. 00:05:42.920 --> 00:05:45.060 Beleid, de motor die alles aanstuurt. 00:05:45.260 --> 00:05:47.220 Dus hoe zit het met dat beleid waar ik het over had? 00:05:47.220 --> 00:05:49.840 Het is de motor die API-M echt krachtig maakt. 00:05:50.040 --> 00:05:54.240 Beleid past het gedrag van verzoeken of antwoorden aan zonder dat je je back-end code hoeft aan te raken. 00:05:54.500 --> 00:05:56.300 Zie het als een wrapper rond je API. 00:05:56.560 --> 00:06:00.560 Terwijl verkeer er doorheen stroomt, kan het automatisch zaken toevoegen, verwijderen of wijzigen. 00:06:00.780 --> 00:06:03.960 Beleid kan op vier momenten in de levenscyclus van een verzoek worden uitgevoerd. 00:06:04.160 --> 00:06:07.260 Inbound, op de weg naar binnen, voordat het verzoek je back-end bereikt. 00:06:07.500 --> 00:06:10.480 Outbound, op de weg terug, voordat het antwoord bij de client komt. 00:06:10.760 --> 00:06:13.080 Back-end, vlak voordat het verzoek je service bereikt. 00:06:13.280 --> 00:06:15.360 En bij fouten, wanneer er iets misgaat. 00:06:15.360 --> 00:06:19.860 Veel voorkomende inkomende acties zijn het valideren van JWT-tokens om de identiteit van de aanroeper te controleren, 00:06:19.980 --> 00:06:23.020 API-sleutels verifiëren, URL's herschrijven en beperken op IP-adres. 00:06:23.180 --> 00:06:25.860 Dit alles gebeurt voordat uw back-end ook maar één verzoek ontvangt. 00:06:25.980 --> 00:06:31.980 Voor uitgaand verkeer kunt u de response body transformeren, tekst zoeken en vervangen, gevoelige velden verwijderen, formaten wijzigen. 00:06:32.140 --> 00:06:35.340 U kunt antwoorden cachen zodat herhaalde verzoeken uw back-end niet belasten. 00:06:35.520 --> 00:06:38.080 U kunt zelfs headers verwijderen die interne informatie lekken. 00:06:38.220 --> 00:06:39.480 Hier is een concreet voorbeeld. 00:06:39.480 --> 00:06:43.160 Stel dat uw API-productbeschrijvingen retourneert waar overal het woord blauw in staat. 00:06:43.320 --> 00:06:45.920 U wilt een rebrand doorvoeren en in plaats daarvan geel gebruiken. 00:06:46.080 --> 00:06:49.780 In plaats van uw back-end code aan te passen, voegt u één uitgaand beleid toe. 00:06:50.020 --> 00:06:51.640 Zoek blauw, vervang door geel. 00:06:51.840 --> 00:06:53.920 En klaar, uw back-end verandert nooit. 00:06:54.200 --> 00:06:57.400 Beleid voor rate limiting en quota beschermt uw back-end tegen misbruik. 00:06:57.560 --> 00:07:02.580 Als iemands app op hol slaat en uw API 10.000 keer per seconde bestookt, grijpt het beleid in en zegt, 00:07:02.740 --> 00:07:03.240 rustig aan. 00:07:03.400 --> 00:07:04.700 Uw back-end blijft gezond. 00:07:05.000 --> 00:07:06.160 Geavanceerde logica nodig? 00:07:06.360 --> 00:07:08.860 U kunt aangepaste C-Sharp expressies schrijven binnen beleidsregels. 00:07:09.060 --> 00:07:10.700 Deze worden gecompileerd voor prestaties. 00:07:10.860 --> 00:07:12.200 Er zijn dus geen runtime kosten. 00:07:12.420 --> 00:07:17.680 U kunt gebruikersrollen opzoeken, dynamische limieten berekenen of antwoorden voorwaardelijk transformeren op basis van request headers. 00:07:17.900 --> 00:07:19.440 De belangrijkste conclusie is deze. 00:07:19.640 --> 00:07:23.780 Met beleidsregels kunt u het gedrag van uw APIs bepalen zonder de onderliggende code aan te raken. 00:07:24.020 --> 00:07:27.480 Dat betekent snellere wijzigingen, minder implementaties en minder risico. 00:07:27.720 --> 00:07:30.760 Producten en abonnementen, APIs verpakken voor consumenten. 00:07:30.760 --> 00:07:35.180 Nu uw APIs zijn gedefinieerd, beleid is ingesteld en de gateway soepel draait. 00:07:35.300 --> 00:07:38.040 Maar hoe geeft u verschillende klanten toegang tot verschillende zaken? 00:07:38.300 --> 00:07:40.780 Dat is waar producten en abonnementen om de hoek komen kijken. 00:07:41.000 --> 00:07:44.320 In API-M groepeert u APIs in iets dat een product wordt genoemd. 00:07:44.460 --> 00:07:45.440 Zie het als een bundel. 00:07:45.640 --> 00:07:49.020 U kunt een gratis product hebben dat alleen uw basis APIs bevat. 00:07:49.260 --> 00:07:55.060 Misschien alleen lezen toegang en daarnaast een premium product met alles inclusief schrijfbewerkingen en admin endpoints. 00:07:55.060 --> 00:07:59.100 Ontwikkelaars abonneren zich niet op individuele APIs, ze abonneren zich op een product. 00:07:59.280 --> 00:08:01.740 Wanneer ze zich abonneren, krijgen ze een abonnementsleutel. 00:08:01.860 --> 00:08:04.560 Eigenlijk twee sleutels, zodat u er één kunt vernieuwen zonder downtime. 00:08:04.860 --> 00:08:07.860 Die sleutel is een toegangsbewijs om elke API in dat product te gebruiken. 00:08:08.020 --> 00:08:09.460 U bepaalt hoe abonnementen werken. 00:08:09.700 --> 00:08:11.340 Producten kunnen goedkeuring vereisen. 00:08:11.540 --> 00:08:15.120 U accepteert elke abonnee handmatig of ze kunnen openstaan voor zelfbediening. 00:08:15.280 --> 00:08:17.320 Iedereen kan zich aanmelden en krijgt direct toegang. 00:08:17.320 --> 00:08:20.980 U kunt ook juridische voorwaarden opnemen die gebruikers moeten accepteren voor ze zich abonneren. 00:08:21.120 --> 00:08:23.460 Dat is belangrijk als uw APIs gevoelige gegevens verwerken. 00:08:23.460 --> 00:08:25.160 Dit is hoe u APIs te gelden maakt. 00:08:25.320 --> 00:08:28.160 Een gratis product met lage limieten, 5 aanroepen per minuut. 00:08:28.300 --> 00:08:31.780 Een betaald product met hogere limieten of meer endpoints, 100 aanroepen per minuut, 00:08:31.800 --> 00:08:33.080 plus toegang tot premium functies. 00:08:33.260 --> 00:08:34.500 Uw backend merkt daar niets van. 00:08:34.700 --> 00:08:37.840 De Gateway twinkt limieten af op basis van het product waarop de aanroeper is geabonneerd. 00:08:38.000 --> 00:08:39.200 Hier is een praktijkvoorbeeld. 00:08:39.480 --> 00:08:41.260 Stel je voor dat je een conferentie-app bouwt. 00:08:41.380 --> 00:08:45.700 Je maakt een deelnemersproduct met APIs voor het dagschema, sprekersbiografieën en een plattegrond. 00:08:45.940 --> 00:08:48.900 Daarnaast een sponsorproduct dat ook APIs voor leadgeneratie bevat. 00:08:49.160 --> 00:08:51.960 Sponsors kunnen badges van deelnemers scannen en contactgegevens ophalen. 00:08:51.960 --> 00:08:54.900 Dezelfde backend, verschillende producten, verschillende toegangsniveaus. 00:08:55.100 --> 00:08:57.560 Die twee abonnementsleutels zijn ontworpen voor roulatie. 00:08:57.720 --> 00:09:00.340 Als een sleutel gecompromitteerd raakt, genereer je een nieuwe. 00:09:00.540 --> 00:09:03.500 Met de tweede sleutel kun je overschakelen zonder de dienst te onderbreken. 00:09:03.780 --> 00:09:06.720 Genereer een nieuwe sleutel, update je app en trek de oude in. 00:09:07.040 --> 00:09:07.440 Naadloos. 00:09:07.640 --> 00:09:10.440 De ontwikkelaarsportal, self-service voor API-gebruikers. 00:09:10.640 --> 00:09:12.540 Dus, je hebt je API-producten ingesteld. 00:09:12.740 --> 00:09:14.100 Nu moeten ontwikkelaars ze kunnen vinden. 00:09:14.360 --> 00:09:15.940 Dat is de taak van de ontwikkelaarsportal. 00:09:16.100 --> 00:09:19.300 De ontwikkelaarsportal is een website die in elk API-m-exemplaar is ingebouwd. 00:09:19.300 --> 00:09:24.840 De ontwikkelaars gebruiken deze om je APIs te bekijken, documentatie te lezen en eindpunten interactief te testen in hun browser. 00:09:25.100 --> 00:09:27.140 Geen installatie nodig en geen heen en weer gemail. 00:09:27.320 --> 00:09:29.700 Het punt is echter dat deze standaard niet gepubliceerd is. 00:09:29.940 --> 00:09:33.720 Wanneer je je API-m-exemplaar voor het eerst maakt, bestaat de portal, maar is deze voor niemand zichtbaar. 00:09:33.880 --> 00:09:35.620 Je moet hem eerst aanpassen en publiceren. 00:09:35.880 --> 00:09:36.760 Dat is bewust gedaan. 00:09:37.000 --> 00:09:39.380 Je wilt geen half afgewerkte portal aan de wereld tonen. 00:09:39.520 --> 00:09:44.300 Je kunt merkkleuren en logo's aanpassen en zelfs WordPress-inhoud voor een blog naast je API-documentatie insluiten. 00:09:44.300 --> 00:09:47.300 Het is volledig aanpasbaar aan de uitstraling van je bedrijf. 00:09:47.300 --> 00:09:49.020 De echte waarde is self-service. 00:09:49.360 --> 00:09:54.140 Ontwikkelaars melden zich aan, krijgen automatisch hun abonnementsleutels en kunnen direct APIs aanroepen. 00:09:54.320 --> 00:09:58.960 Geen handmatige e-mails, geen wachttijden voor goedkeuring, geen supporttickets met vragen over sleutels. 00:09:59.140 --> 00:10:02.120 Ze doen het zelf, wat je werklast voor ondersteuning aanzienlijk vermindert. 00:10:02.280 --> 00:10:04.920 Je kunt ook wijzigingslogs en release-opmerkingen publiceren. 00:10:05.200 --> 00:10:08.940 Wanneer je een API bijwerkt, zien ontwikkelaars dit direct in de portal zonder verrassingen. 00:10:08.940 --> 00:10:16.960 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. 00:10:17.200 --> 00:10:19.800 Beide opties bestaan voor verschillende gebruikscenario's. 00:10:19.960 --> 00:10:22.900 De ontwikkelaarsportal maakt van je API-beheer een echt platform. 00:10:23.180 --> 00:10:24.880 Zie het als de etalage voor je APIs. 00:10:25.220 --> 00:10:28.420 Zonder deze portal moeten ontwikkelaars door documentatie zoeken en rondvragen. 00:10:28.680 --> 00:10:31.740 Met deze portal vinden ze wat ze nodig hebben en kunnen ze direct bouwen. 00:10:31.740 --> 00:10:35.320 Beveiliging, authenticatie, autorisatie en geheimen. 00:10:35.500 --> 00:10:38.560 Al deze kracht is nutteloos als de beveiliging niet op orde is. 00:10:38.800 --> 00:10:42.140 Laten we het dus hebben over hoe API-M identiteit, toegang en geheimen beheert. 00:10:42.300 --> 00:10:44.780 API-M ondersteunt meerdere authenticatie-methoden. 00:10:44.940 --> 00:10:47.880 De eenvoudigste zijn abonnementsleutels, waar we het eerder over hadden. 00:10:47.880 --> 00:10:54.160 Maar voor productiesystemen wil je iets sterkers, zoals OAuth 2.0, JWT-tokens, client-certificaten of IP-filtering. 00:10:54.360 --> 00:10:57.160 Je brengt deze in lagen aan op basis van hoe gevoelig je API is. 00:10:57.340 --> 00:11:00.940 Voor productie is het gebruik van OAuth 2.0 met entra-ID the best practice. 00:11:00.940 --> 00:11:01.880 Zo werkt dat. 00:11:02.020 --> 00:11:05.920 De client-app krijgt een token van entra-ID en verstuurt dit bij de API-aanvraag. 00:11:06.180 --> 00:11:10.720 API-M valideert het token door de handtekening, uitgever, doelgroep en verloopdatum te controleren. 00:11:10.860 --> 00:11:14.440 Als het geldig is, stuurt API-M de aanvraag inclusief token door naar je backend. 00:11:14.440 --> 00:11:19.360 Je backend vertrouwt dit omdat API-M het al heeft gecontroleerd, dus je backend hoeft niet opnieuw te valideren. 00:11:19.520 --> 00:11:22.100 Dat is weer één ding minder dat elke service zelf moet afhandelen. 00:11:22.340 --> 00:11:23.680 Laten we het nu over geheimen hebben. 00:11:23.900 --> 00:11:28.660 API-sleutels, connection-strings en certificaten wil je niet hardcodet in beleidsbestanden of broncodebeheer hebben. 00:11:28.660 --> 00:11:31.360 API-M heeft een functie genaamd named values. 00:11:31.560 --> 00:11:35.300 Je slaat geheimen centraal op in API-M en verwijst er in je beleid naar bijnaam. 00:11:35.440 --> 00:11:37.800 De werkelijke waarde verschijnt nooit in je beleidscode. 00:11:38.080 --> 00:11:40.920 Sterker nog, je kunt named values koppelen aan Azure Key Vault. 00:11:40.920 --> 00:11:44.420 De geheimen blijven versleuteld in Key Vault en API-M haalt ze op tijdens runtime. 00:11:44.660 --> 00:11:47.660 Niemand, zelfs je DevOps-team niet, ziet de werkelijke waarde van het geheim. 00:11:47.860 --> 00:11:52.800 Wanneer je een sleutel moet roteren, update je deze in Key Vault en API-M verwerkt de wijziging automatisch. 00:11:53.000 --> 00:11:55.400 API-M ondersteunt ook beheerde identiteiten. 00:11:55.400 --> 00:12:01.900 Hiermee kan API-M verifiëren bij andere Azure-services, zoals Key Vault of een back-end API, zonder inloggegevens op te slaan. 00:12:02.060 --> 00:12:04.820 Azure beheert de identiteit, dus jij hoeft alleen rechten toe te kennen. 00:12:05.040 --> 00:12:08.760 En voor netwerkisolatie kun je API-M binnen een virtueel netwerk implementeren. 00:12:09.000 --> 00:12:10.320 Dat is de premium laag. 00:12:10.640 --> 00:12:12.240 Of gebruik Azure Frontdoor. 00:12:12.460 --> 00:12:17.060 Het punt is dat je back-end services nooit direct aan het internet blootgesteld hoeven te worden. 00:12:17.440 --> 00:12:19.980 API-M is het enige wat de buitenwereld ziet. 00:12:20.240 --> 00:12:22.860 Deze gelaagde aanpak bouwt een verdediging in de diepte op. 00:12:22.860 --> 00:12:27.660 Authenticatie bij de gateway, geheimen in een kluis, netwerkisolatie rondom je back-ends. 00:12:27.860 --> 00:12:29.480 Elke laag versterkt de volgende. 00:12:30.480 --> 00:12:31.900 Prijsniveaus, welke past bij jou? 00:12:32.120 --> 00:12:33.080 Dus, wat kost het? 00:12:33.240 --> 00:12:34.500 Laten we de niveaus doornemen. 00:12:34.720 --> 00:12:36.260 De verbruik laag, consumption tier. 00:12:36.460 --> 00:12:38.720 Betaal per API aanroep zonder vaste maandelijkse kosten. 00:12:38.920 --> 00:12:42.140 Perfect voor laag volume of piekbelastingen, zoals wanneer je aan het prototype bent. 00:12:42.320 --> 00:12:44.480 Als je nog niet zeker weet wat je nodig hebt, begin dan hier. 00:12:44.660 --> 00:12:48.100 De ontwikkelaarslaag, developer tier, geeft je vaste lage maandelijkse kosten van ongeveer 50 dollar. 00:12:48.400 --> 00:12:49.900 Volledige functieset, maar geen sla. 00:12:50.060 --> 00:12:51.760 Ideaal voor ontwikkel- en testomgevingen. 00:12:51.840 --> 00:12:54.300 Je krijgt alles wat premium heeft, maar je mag het niet gebruiken voor productie. 00:12:54.460 --> 00:12:56.800 De basislaag, basic tier, is het instapniveau voor productie. 00:12:56.960 --> 00:13:00.360 Lagere doorvoer, geen ondersteuning voor virtuele netwerken, maar je krijgt wel een echte sla. 00:13:00.540 --> 00:13:04.260 Geschikt voor interne tools of kleine projecten waar privé-netwerken niet cruciaal zijn. 00:13:04.480 --> 00:13:05.900 De meeste bedrijven kiezen voor de standaardlaag. 00:13:06.660 --> 00:13:11.800 Inclusief ondersteuning voor virtuele netwerken, een sla van 99,95 procent en goede doorvoer. 00:13:11.960 --> 00:13:15.200 Als je bedrijfscritieke APIs draait, is dit waarschijnlijk waar je uitkomt. 00:13:15.200 --> 00:13:19.820 De premiumlaag is voor wereldwijde ondernemingen die maximale betrouwbaarheid en privé-netwerken nodig hebben. 00:13:20.020 --> 00:13:25.720 Multi-regio-implementatie, self-hosted gateway, sla van 99,99 procent, volledige virtuele netwerkinjectie. 00:13:25.840 --> 00:13:28.560 Begint bij ongeveer 2700 per maand per eenheid. 00:13:28.740 --> 00:13:32.980 Microsoft introduceerde ook V2-lagen Basic V2, Standard V2 en Premium V2. 00:13:33.220 --> 00:13:36.980 Zij vereenvoudigen de prijsstelling met inbegrepen aanvraagquota en kosten per miljoen overschrijdingen. 00:13:37.080 --> 00:13:42.100 In plaats van meerdere meters bij te houden, krijg je een duidelijk pakket aanvragen en betaal je voor extra gebruik in eenvoudige stappen. 00:13:42.100 --> 00:13:43.280 Zo maak je een keuze. 00:13:43.500 --> 00:13:45.020 Begin met developer voor het testen. 00:13:45.180 --> 00:13:46.840 Stap over naar Standard voor productie. 00:13:47.000 --> 00:13:49.920 Kies premium als je wereldwijde schaal- of privé-netwerken nodig hebt. 00:13:50.100 --> 00:13:52.500 En vergeet niet, je kunt later altijd nog van laag wisselen. 00:13:52.680 --> 00:13:54.900 Begin klein een groei naarmate je behoefte veranderen. 00:13:55.080 --> 00:13:56.020 Dit hebben we behandeld. 00:13:56.240 --> 00:14:02.360 API-beheer brengt de chaos van vele APIs samen in één controlecentrum voor gateways, beleid, beveiliging en ontwikkelaarservaring. 00:14:02.560 --> 00:14:04.600 De belangrijkste lay is dat het meer is dan een proxy. 00:14:04.900 --> 00:14:07.780 Zie het als het brein- en het zenuwstelsel van je API-ecosysteem. 00:14:07.780 --> 00:14:11.140 Zonder dit bouwt elk team hun eigen authenticatie, logging en rate-limiting. 00:14:11.320 --> 00:14:15.320 Je eindigt met inconsistentie, beveiligingslekken en geen enkel overzicht van wat er gebeurt. 00:14:15.520 --> 00:14:21.440 Met dit beheer krijg je consistentie, beveiliging en schaalbaarheid zonder voor elke service het wiel opnieuw uit te vinden. 00:14:21.660 --> 00:14:22.980 Hier is een simpele oefening. 00:14:23.280 --> 00:14:25.920 Denk aan één API die je momenteel direct blootstelt. 00:14:26.180 --> 00:14:28.280 Misschien een functie-at-point of een app-service. 00:14:28.540 --> 00:14:33.020 Hoe zou het plaatsen van API-beheer ervoor zorgen dat je beveiligingsniveau en monitoring veranderen? 00:14:33.020 --> 00:14:35.900 Alleen al door die oefening te overwegen, zul je de waarde inzien. 00:14:36.120 --> 00:14:37.940 Volgende stap, abonneer je op het kanaal. 00:14:38.080 --> 00:14:43.580 In toekomstige afleveringen laten we zien hoe je een API importeert, je eerste beleid toepast en gebruik in real-time monitort. 00:14:43.760 --> 00:14:45.400 Je gaat van theorie naar de praktijk. 00:14:45.580 --> 00:14:48.080 En als je dit nuttig vond, deel het dan met iemand die een app bouwt. 00:14:48.220 --> 00:14:49.900 Het bespaart hen maanden aan hoofdpijn. 00:14:50.120 --> 00:14:51.160 Bedankt voor het luisteren.