Willkommen zu einer neuen Folge von Microsoft Knowledge Nuggets. Ich bin Ihr Gastgeber Mirko Peters. Unser heutiges Thema ist etwas, das fast jeder schon einmal gehört hat, aber nur wenige wirklich verstehen. APIs. Sie haben den Begriff wahrscheinlich schon oft gehört. Es ist eines dieser Fachwörter, die Leute benutzen, wenn sie kompetent klingen wollen. Aber wissen Sie was? APIs sind eigentlich ganz einfach. Sie sind lediglich ein Weg für Software, mit anderer Software zu kommunizieren. Ihr Telefon fragt einen Server nach Daten. Der Server sendet Sie zurück. Das ist ein API-Aufruf. Stellen Sie sich nun vor, Sie hätten 20 APIs oder 50 oder 100. Jede könnte eine andere Authentifizierung, andere Ratenbegrenzungen und eine andere Dokumentation haben, falls überhaupt. Plötzlich wird aus der einfachen Unterhaltung zwischen zwei Apps das totale Chaos. Ohne zentrales Management erfindet jedes Team das Rad neu, baut sein eigenes Authentifizierungssystem, ein anderes seine eigene Protokollierung.

Überall entstehen Sicherheitslücken. Entwickler sind verwirrt, welche API was macht und Sie haben keinen Überblick darüber, was im gesamten System passiert. Azure API Management löst genau das. Es bietet Ihnen ein einziges Kontrollzentrum. Stellen Sie es sich wie einen Fluglotsynturm für Ihre APIs vor. Am Ende dieser Folge werden Sie verstehen, was es ist, warum es wichtig ist und wie alles zusammenpasst. Nehmen Sie sich einen Kaffee und legen wir los. Das Problem, zu viele APIs, keine Kontrolle. Das ist die Realität moderner Software. Vor zehn Jahren hatten Sie wahrscheinlich eine große Anwendung, einen Monolithen, eine Datenbank, eine API-Simple. Heute ist dieselbe Anwendung vielleicht in Dutzende von Microservices unterteilt. Jeder Dienst übernimmt eine Aufgabe, Benutzerkonten, Zahlungen, Inventar, Benachrichtigungen und bietet eine eigene API. Plötzlich haben Sie 10, 50 oder 100 verschiedene Einstiegspunkte in Ihr System.

Stellen Sie sich nun vor, Sie sind Entwickler und wollen etwas bauen, das diese APIs nutzen. Sie müssen jeder einzeln finden und die jeweilige Authentifizierung herausfinden. Manche nutzen API-Keys, manche OAuth, manche gar nichts. Sie müssen die Ratenbegrenzung manuell steuern, sonst riskieren Sie eine Sperre. Sie müssen das Datenformat verstehen, das jede API erwartet. Es ist anstrengend. Und aus operativer Sicht wird es noch schlimmer. Ohne ein zentrales Gateway muss jedes Team Sicherheit und Logging von Hand in seinen Dienst einbauen. Manche Teams machen das gut, andere vergessen die Fehlerprotokollierung. Einige validieren Eingaben überhaupt nicht. Inkonsistent und fehleranfällig, ein Sicherheitsalbtraum, der nur darauf wartet, zu passieren. Compliance wird fast unmöglich. Sie müssen nachweisen, wer wann auf etwas zugegriffen hat. Viel Glück dabei, Audit-Trails aus 20 verschiedenen Diensten mit jeweils eigenem Protokollformat zusammenzusuchen.

Sie müssen wissen, wie viele API-Aufrufe Ihr System im letzten Monat verarbeitet hat. Sie suchen sich Ihre Metriken aus einem Dutzend verschiedener Dashboards zusammen. Erster Punkt. Wenn Sie skalieren, ist das nicht nur mühsam. Scheitert. Sie können ohne zentralen Kontrollpunkt nicht mehr Entwickler, Dienste oder Kunden hinzufügen. Stellen Sie sich das wie ein Gebäude vor. Jeder Raum hat ein anderes Schloss. Es gibt weder ein Empfang noch ein Verzeichnis. Besucher irren umher, finden die richtige Tür nicht, werden frustriert und geben schließlich auf. Vollständiges K. Genau dieses Problem soll IP-Management lösen. Was ist Azure API-Management? Der Kontrollturm. Was genau ist also Azure API-Management? Die einfachste Definition. Es ist ein verwalteter Dienst, der zwischen Ihren Backend-APIs und den Apps, Websites, Geräten und Partnern steht, die Sie nutzen. Aber wichtig ist, es ist nicht nur ein Proxy.

Ein Proxy leitet nur Datenverkehr weiter, das ist er. Azure API-Management deckt den gesamten Lebenszyklus Ihrer APIs an. Veröffentlichen, sichern, überwachen und schließlich außer Betrieb nehmen. Es ist ein vollständiges Kontrollzentrum. Lassen Sie uns das in drei Hauptkomponenten unterteilen. Die erste ist das Gateway. Das ist die Eingangstür. Jede Anfrage von einer App oder Website trifft zuerst auf das Gateway, niemals direkt auf Ihr Backend. Das Gateway verarbeitet die Anfrage, setzt eingerichtete Richtlinien durch, sammelt Metriken und leitet sie an den richtigen Backend-Dienst weiter. Stellen Sie sich wie einen Verkehrspolizisten. Als nächstes kommt die Management eben. Hier definieren Sie alles. Ihre APIs, Ihre Richtlinien, Ihre Produkte, Ihre Abonnements. Dies geschieht über das Azure-Portal, die Befehlszeile oder Infrastructure-AS-Code wie BICEP oder Terraform. Es ist der Kontrollraum, in dem Sie die Funktionsweise von allem konfigurieren.

Und dann das Entwicklerportal. Dies ist eine Self-Service-Website, auf der interne und externe Entwickler ihre APIs entdecken, Dokumentationen lesen, Abonnementschlüssel erhalten und AP-Aufrufe direkt im Browser testen können und APA. Kein Hin- und Herschicken von PDFs per E-Mail mehr. Ihr hilft eine Analogie. Denken Sie an einen modernen Flughafen. Das Gateway ist die Landebahn. Jedes Flugzeug landet zuerst dort. Die Management-Ebene ist der Kontrollturm. Er leitet den Verkehr, legt Regeln fest und überwacht alles. Und das Entwicklerportal ist die Informationstafel. Piloten prüfen Sie vor dem Flug und finden alle benötigten Informationen, ohne mit jemandem sprechen zu müssen. Lassen Sie uns in das Gateway genauer betrachten. Das ist der Teil, mit dem Ihre Apps tatsächlich kommunizieren und wo die Magie passiert. Das Gateway, die Eingangstür zu Ihrer API. Lassen Sie uns über das Gateway sprechen, denn dies ist der Teil, mit dem Ihre Apps tatsächlich kommunizieren.

Jede Anfrage von einer mobilen App, einer Website oder einem IoT-Gelett trifft zuerst auf das Gateway. Niemals direkt auf Ihr Backend. Genau das ist Ihre Sache. Das Gateway steht davor und fungiert als zentraler Einstiegspunkt. Das Gateway kann Richtlinien anwenden, bevor die Anfrage weitergeleitet wird. Richtlinien sind Regeln, die Sie in XML oder JSON schreiben, die etwa Ratenbegrenzung, IP-Filterung, Header-Umschreibung und Authentifizierungsprüfungen. Alles ohne einzige Zeile Ihres Backend-Codes zu ändern. Hier ist ein konkretes Beispiel. Nehmen wir an, Sie haben eine kostenlose und eine Prämienstufe für Ihre API. Mit einer Richtlinie können Sie kostenlose Nutzer auf fünf Anfragen pro Minute begrenzen, während Premium-Nutzer 100 erhalten. Ihr Backend bemerkt davon nichts. Es verarbeitet einfach nur Anfragen. Das Gateway kümmert sich um die Durchsetzung. Das Gateway übernimmt auch das Caching.

Wenn Daten immer wieder angefragt werden, wie eine Produktliste, die sich selten ändert, kann das Gateway die Antwort zwischenspeichern und direkt bereitstellen. Und direkt bereitstellen. Ihr Backend muss überhaupt nicht belastet werden, was schnellere Antworten und weniger Serverlast bedeutet. Es kann auch Daten transformieren. Ihr Backend liefert vielleicht XML, aber Ihre mobile App erwartet JSON. Das Gateway kann die Sound-the-Fly konvertieren. Ihr Backend muss sich nicht ändern und Ihre App ebenfalls nicht. Das Gateway übernimmt die Übersetzung. Zudem protokolliert es jeden Aufruf, jede Anfrage, jede Antwort und jeden Fehler. Sie erhalten einen vollständigen Audit-Trail darüber, wer was wann aufgerufen hat und was passiert ist. Das allein ist für die Compliance schon Gold wert. Wenn Sie ein globales Publikum haben, können Sie das Gateway in mehreren Regionen bereitstellen. Der Datenverkehr wird automatisch zur nächstgelegenen Instanz geleitet, was für geringere Latenz und ein besseres Erlebnis sorgt.

Noch etwas, das Gateway verbirgt die echte URL Ihres Backends. Clients sind nur die Adresse des Gateways. Ihre Backend-Server bleiben vor dem Internet verborgen. Das ist ein enormer Sicherheitsvorteil direkt ab Werk. Richtlinien, die Engine, die alles steuert. Was hat es also mit diesen erwähnten Richtlinien aus? Sie sind der Motor, der App ihm so leistungsfähig macht. Eine Richtlinie modifiziert das Anfrage- oder Antwortverhalten, ohne dass Sie Ihren Backend-Code jemals anfassen müssen. Betrachten Sie es als einen Wrapper um Ihre API. Wenn Datenverkehr hindurchfließt, können Dinge automatisch hinzugefügt, entfernt oder geändert werden. Richtlinien können an vier Punkten im Lebenszyklus eine Anfrage ausgeführt werden. Inbound, beim Eingang, bevor die Anfrage Ihr Backend erreicht. Outbound, auf dem Rückweg, bevor die Antwort den Client erreicht. Backend, kurz bevor die Anfrage Ihren Dienst trifft.

Und bei Fehlern, wenn etwas schief geht. Zu den gängigen eingehenden Funktionen gehören die Validierung von J2T-Token zur Identitätsprüfung. Die Kontrolle von API-Schlüsseln, das Umschreiben von URLs und die IP-Adress-Beschränkung. All dies geschieht, bevor Ihr Backend eine einzige Anfrage erhält. Für ausgehende Anfragen können Sie den Antwortkörperdassensummen. Suchen und ersetzen Sie Text, entfernen Sie sensible Felder und ändern Sie Format. Sie können Antworten zwischenspeichern, sodass wiederholte Anfragen Ihr Backend nicht belasten. Sie können sogar Header entfernen, die interne Informationen preisgeben. Hier ist ein konkretes Beispiel. Angenommen, Ihre API liefert Produktbeschreibungen, in denen überall das Wort Blau vorkommt. Sie möchten ein Rebranding durchführen, stattdessen Gipfel. Anstatt Ihren Backend-Code zu ändern, fügen Sie eine ausgehende Richtlinie hinzu. Suchen Sie nach Blau, ersetzen Sie es durch Gelb und fertig.

Ihr Backend ändert sich dabei nicht. Ratenbegrenzungs- und Kontingtrichtlinien schützen Ihr Backend vermissbar. Wenn eine App amok läuft und Ihre API 10.000 Mal pro Sekunde bombardiert, greift die Richtlinie ein und sagt Eingang runterschalten. Ah, Ihr Backend bleibt stabil. Benötigen Sie erweiterte Logik? Sie können benutzerdefinierte C-Schalte-Ausdrücke innerhalb von Richtlinien schreiben. Diese werden für mehr Leistung kompiliert. Es entstehen also keine Laufzeitkosten. Sie können Benutzerrollen nachschlagen, dynamische Ratenlimits berechnen oder Antworten basierend auf Anfrageheadern bedingt transformieren. Das Wichtigste ist Folgendes. Richtlinien ermöglichen es Ihnen, das Verhalten Ihrer APIs zu steuern, ohne den zugrunde liegenden Code zu berühren. Das bedeutet schnellere Änderungen, weniger Deployments und weniger Risiko. Produkte und Abonnements. Das Verpacken von APIs für Endanwender.

Nun sind Ihre APIs definiert, Richtlinien eingerichtet und das Gateway läuft einwandfrei. Aber wie gewähren Sie verschiedenen Kunden Zugriff auf unterschiedliche Dinge? Hier kommen Produkte und Abonnements ins Spiel. In APIM gruppieren Sie APIs in sogenannten Produkten. Jen sieht sich wie ein Bündelform. Sie könnten ein kostenloses Basisprodukt haben, das nur Ihre grundlegenden APIs enthält. Vielleicht nur Lesezugriff und dazu ein Premium-Produkt, das alles enthält, einschließlich Schreibvorgängen und Admin-Endpunkten. Entwickler abonnieren keine einzelnen APIs, Sie abonnieren ein Produkt. Bei der Anmeldung erhalten Sie einen Abonnementschlüssel. Eigentlich zwei Schlüssel, damit Sie einen ohne Auswahlzeit rotieren können. Dieser Schlüssel ist Ihre Eintrittskarte zur Nutzung jeder API in diesem Produkt. Sie steuern, wie Abonnements funktionieren. Produkte können eine Genehmigung erfordern.

Sie können jeden Abonnenten manuell akzeptieren. Oder Sie können für den Self-Service offen sein. Jeder kann sich anmelden und erhält sofortigen Zugriff. Sie können auch rechtliche Bedingungen hinzufügen, die Benutzer vor dem Abonnieren akzeptieren müssen. Das ist wichtig, wenn Ihre APIs sensibel Daten verarbeiten. Auf diese Weise monetarisieren Sie Ihre APIs. Ein kostenloses Produkt mit niedrigen Limits, 5 Aufrufe pro Minute. Ein kostenpflichtiges Produkt mit höheren Limits oder mehr Endpunkten, 100 Aufrufe pro Minute plus Zugriff auf Premium-Funktion. Ihrem Backend ist das egal. Das Gateway erzwingt die Limits basierend auf dem Produkt, das der Aufrufer abonniert hat. Hier ist ein praktisches Beispiel. Stellen Sie sich vor, Sie entwickeln eine Konferenz ab. Sie erstellen ein Teilnehmerprodukt mit APIs für den Sitzungsplan, Referentenbiografien und den Lageplan. Dann ein Sponsorenprodukt, das zusätzliche APIs zur Lead-Generierung enthält.

Sponsoren können Teilnehmerausweise scannen und Kontaktinformationen abrufen. Gleiches Backend, verschiedene Produkte, unterschiedliche Zugriffsebenen. Diese beiden Abonnementschlüssel sind für die Rotation konzipiert. Falls ein Schlüssel kompromittiert wird, generieren Sie einfach einen neuen. Mit dem zweiten Schlüssel können Sie wechseln, ohne den Dienst zu unterbrechen. Neuen Schlüssel generieren, App aktualisieren, den alten sperren. Ab los! Das Entwicklerportal. Self-Service für API-Nutzer. Sie haben also Ihre API, Ihr Produkt eingerichtet. Jetzt müssen Entwickler diese finden. Das ist die Aufgabe des Entwicklerportals. Das Entwicklerportal ist eine Website, die in jede API-Instanz integriert ist. Entwickler nutzen es, um ihre APIs zu durchsuchen, die Dokumentation zu lesen und Endpunkte interaktiv direkt im Browser zu testen. Keine Einrichtung erforderlich und kein Hin- und Herschreiben von E-Mails.

Die Sache ist jedoch die, es ist standardmäßig nicht veröffentlicht. Wenn Sie Ihre API-Ministanz erstmals erstellen, existiert das Portal, aber niemand kann es sehen. Sie müssen es zuerst anpassen und veröffentlichen. Das ist beabsichtigt. Sie möchten der Welt kein halbfertiges Portal zeigen. Sie können Markenfarben und Logos anpassen oder sogar WordPress-Inhalte für einen Blog neben Ihrer API-Dokumentation einbetteln. Es ist vollständig an das Erscheinungsbild Ihres Unternehmens anpassbar. Der wahre Mehrwert liegt im Self-Service. Entwickler registrieren sich, erhalten Ihre Abonnementschlüssel automatisch und können sofort API-Aufrufe starten. Keine manuellen E-Mails, kein Wadenaufgenehmigungen, keine Support-Tickets mit Fragen zum Erhalt eines Schlüssels. Sie erledigen das selbst, was Ihren Support-Aufwand erheblich reduziert. Sie können auch Änderungsprotokolle und Versionshinweise veröffentlichen.

Wenn Sie eine API aktualisieren, sehen Entwickler dies im Portal ohne Überraschungen. Der Zugriff kann öffentlich für jeden mit der URL sein oder auf Benutzer Ihres N3-ID-Tenants beschränkt werden, sodass nur Mitarbeiter Ihres Unternehmens stöbern können. Beide Optionen existieren für unterschiedliche Anwendungsfälle. Das Entwicklerportal macht die API-Management zu einer echten Plattform. Betrachten Sie es als das Schaufenster für Ihre APIs. Ohne das Portal müssen Entwickler Dokumente durchsuchen und herumfragen. Mit dem Portal finden Sie, was Sie brauchen und können mit dem Bauen beginnen. Sicherheit, Authentifizierung, Autorisierung und Geheimnisse. All diese Leistungsfähigkeit ist nutzlos, wenn die Sicherheit nicht gewährleistet ist. Sprechen wir also darüber, wie API im Identität, Zugriff und Geheimnisse handhaben. API im unterstützt mehrere Authentifizierungsmethoden. Die einfachsten sind Abonnementschlüsse, über die wir vorhin gesprochen haben.

Für Produktionssysteme benötigen Sie jedoch etwas Stärkeres wie OAuth 2.0, JBT-Tokens, Client-Zertifikate oder IP-Filterung. Sie setzen diese je nach Sensibilität Ihrer API gestaffelt ein. Für die Produktion ist die Verwendung von OAuth 2.0 mit EntraID bewährte Methode. So funktioniert das. Die Client-App erhält ein Token von EntraID und sendet es mit der API-Anfrage. API im validiert das Token, indem es Signatur, Aussteller, Zielgruppe und Ablaufdatum prüft. Wenn es gültig ist, leitet API im die Anfrage einschließlich des Tokens an Ihr Backend weiter. Ihr Backend vertraut darauf, da API es bereits geprüft hat, sodass Ihr Backend nicht erneut validieren muss, Sir. Das ist eine Aufgabe weniger, um die sich jeder Dienst kümmern muss. Kommen wir nun zu den Geheimnissen. API-Schlüssel, Verbindungszeichenfolgen oder Zertifikate sollten nicht fest in Richtliniendateien oder Quellcode stehen. API im bietet eine Funktion namens benannte Werte.

Sie speichern Geheimnisse zentral in API im und verweisen in Ihren Richtlinien per Name drauf. Der tatsächliche Wert erscheint niemals in Ihrem Richtliniencode. Besser noch, Sie können benannte Werte mit Azure Key Vault verknüpfen. Die Geheimnisse bleiben in Key Vault verschlüsselt und API im ruft Sie zur Laufzeit ab. Niemand nicht einmal Ihr DevOps-Team sieht den eigentlichen Wert des Geheimnisses. Wenn Sie einen Schlüssel rotieren müssen, aktualisieren Sie ihn in Key Vault und API übernimmt die Änderung automatisch. API unterstützt auch verwaltete Identitäten. Dadurch kann sich API bei anderen Azure-Diensten wie Key Vault oder einer Backend-API authentifizieren, ohne Anmeldedaten zu speichern. Azure verwaltet die Identität, Sie müssen also nur die Berechtigung geteilt. Und zur Netzwerksisolierung können Sie API innerhalb eines virtuellen Netzwerks bereitstellen. Das ist der Premium-Tabie.

Oder nutzen Sie Azure Front Door. Der Punkt ist, dass Ihre Backend-Dienste nie direkt dem Internet ausgesetzt sein müssen. API ist das Einzige, was die Außenwelt zu sehen bekommt. Dieser mehrschichtige Ansatz sorgt für eine tiefgestaffelte Verteidigung. Authentifizierung am Gateway. Geheimnisse im Tresor. Netzwerksisolierung um Ihre Backends. Jede Ebene stärkt die nächste. Preistarife, welcher passt zu Ihnen? Was kostet das Ganze aus? Geben wir die Tarife einmal durch. Der Verbrauchstarif kann. Bezahlen Sie pro API-Aufruf ohne feste monatliche Kosten. Perfekt für geringes Volumen oder sporadische Arbeitslasten, etwa beim Prototyping. Wenn Sie noch nicht sicher sind, was Sie brauchen, fangen Sie an. Der Entwicklertarif-Developer bietet feste niedrige monatliche Kosten von etwa 50 Dollar. Voller Funktionsumfang, aber ohne SLA. Ideal für Entwicklungs- und Testumgebungen. Sie erhalten alles, was Premium bietet, dürfen Sie aber nicht für die Produktion nutzen.

Der Basistarif ist der Einstieg für die Produktion. Geringerer Durchsatz, keine Unterstützung für virtuelle Netzwerke, aber Sie erhalten eine echte SLA. Gut für interne Tools oder kleine Projekte, bei denen private Netzwerke nicht kritisch sind. Die meisten Unternehmen entscheiden sich für den Standardtarif. Er umfasst Unterstützung für virtuelle Netzwerke, eine 9,9,5 SLA und einen guten Durchsatz. Wenn Sie geschäftskritische APIs betreiben, ist dies wahrscheinlich die richtige Wahl. Der Premium-Tarif ist für globale Unternehmen, die maximale Zuverlässigkeit und private Netzwerke benötigen. Multi-Region-Bereitstellung, selbst gehostetes Gateway, 9,9,5 SLA, vollständige Integration virtueller Netzwerke. Beginnt bei etwa 2.700 pro Monat und Einheit. Microsoft hat außerdem V2-Tarifereing geführt. Basic V2, Standard V2, Premium V2. Sie vereinfachen die Preisgestaltung durch enthaltene Anforderungskontingente und Kosten pro Million Euro.

Statt mehrere Zähler zu verfolgen, erhalten Sie ein festes Anforderungskontingent und zahlen mehr Nutzung in einfachen Schritten. So treffen Sie die richtige Wahl. Beginnen Sie für Tests mit dem Developer-Tarif. Wechseln Sie für die Produktion zustande. Wählen Sie Premium, wenn Sie globale Skalierung oder private Netzwerke benötigen. Denken Sie daran, Sie können später jederzeit in andere Tarife migrieren. Fangen Sie klein an und wachsen Sie mit Ihren Anforderungen. Das haben wir beim. API-Management ordnet das Chaos vieler APIs und vereint Sie in einem Kontrollzentrum für Gateway, Richtlinien, Sicherheit und Entwicklererfahrung. Die wichtigste Erkenntnis ist mehr als nur ein Proxy. Betrachten Sie es als das Gehirn- und Nervensystem Ihres API-Ökosystems. Ohne die Spot jedes Team eigene Lösungen für Authentifizierung, Logging und Raten begrenzen. Das Ergebnis sind Inkonsistenzen, Sicherheitslücken und fehlender Überblick über die Vorgänge.

Damit erhalten Sie Konsistenzsicherheit und Skalierbarkeit, ohne das Rad, für jeden Dienst neu zu erfinden. Eine einfache Übung. Denken Sie an eine API, die Sie derzeit direkt bereitstellen. Vielleicht einen Funktionsendpunkt oder einen App-Service. Wie würde sich API-Management davor auf Ihre Sicherheit und Überwachungsmöglichkeiten auswirken? Allein das Durchdenken dieser Übung zeigt Ihnen den Wert. Nächster Schritt, abonnieren Sie den Kanal. In künftigen Folgen zeigen wir, wie Sie eine API importieren, Ihre erste Richtlinie anwenden und die Nutzung in Echtzeit überwachen. Sie kommen von der Theorie zur Praxis. Und wenn das hilfreich war, teilen Sie es mit jemandem, der eine App entwickelt. Es erspart Ihnen monatelange Kopfschmerz. Vielen Dank fürs Zuhören.