Im Kontext eines Architektur- oder Systementwurfs bezieht sich API-Management in der Regel auf einen konfigurierbaren, hochleistungsfähigen Reverseproxy, der zum Verwalten des (externen, internen oder anderweitigen) Zugriffs von Clients auf eine API, einen Endpunkt oder eine Methode verwendet wird. API-Management wird häufig, aber nicht ausschließlich, mit RESTful-APIs verwendet und bietet eine Ebene der Anforderungsverwaltung und des Schutzes, sodass eine eingehende Anforderung verifiziert, überprüft, geändert und bearbeitet werden kann und die vom Backend-System zurückgegebene Antwort weiter geändert oder bearbeitet werden kann. Einige Organisationen verwenden möglicherweise einen Enterprise Service Bus, um ähnliche Ziele zu erreichen. Ein Enterprise Service Bus ist ein flexibel definierter Begriff für eine Klasse von Technologien, die zusätzliche Auswirkungen auf diese Komponente haben, aber von den gleichen Empfehlungen für API-Management-Services profitieren können.
Beispiele für API-Management-Systeme sind unter anderem diese:
Das Verhalten des API-Management unterscheidet sich von einem herkömmlichen Reverseproxy, der in der Regel ein vollständiges Muster des HTTP-Datenverkehrs an einen Backend-Server weiterleitet. Beispiel:
<externer_host>:443/server/rest/services/* » <interner_host>>:6443/arcgis/rest/services/*
Das API-Management umfasst oft die Auswahl einzelner API-URI-Pfade und HTTP-Methoden (d. h. eine POST-Anforderung an /routes/extract und eine PATCH-Anforderung an /routes/<routeid>). Dies bedeutet, dass jede einzelne Methode oder jedes einzelne Muster definiert werden muss, aber auch, dass jedes Muster unterschiedliche Regeln, Verhaltensweisen und Backend-Listener oder -Services haben kann. Dies wird häufig bei der Erstellung neuer APIs oder Systeme verwendet, bei denen kein Satz von Web-Services vorhanden ist, oder bei der Unterstützung einer Architektur im Microservices-Stil, bei der verschiedene Backend-Komponenten oder -Systeme für die Verarbeitung separater API-Anforderungen verantwortlich sind. In einigen Fällen kann das API-Management eine Backend-API-Definition (z. B. eine OpenAPI-Spezifikation) verwenden, um viele Frontend-Endpunkte oder -Methoden zu erstellen.
Das API-Management umfasst in der Regel auch eine Reihe anderer Verarbeitungsoptionen, die entweder den Inhalt der Anforderung bearbeiten (Anpassen oder Umschreiben eines Pfades, Hinzufügen oder Ändern eines Headers, Ändern des Zieles basierend auf dem Inhalt des POST-Textes), einige Filter auf die Anforderung anwenden (Ratenbegrenzung, Blockieren bestimmter IP-Bereiche, Anfordern von API-Schlüsseln) oder die Antwort bearbeiten (Verschleierung von Servernamen, Entfernen von Antwort-Headern, Hinzufügen eines Fingerabdrucks oder einer Kennung). Diese Vorgänge werden in der API-Managementschicht definiert und wirken sich auf jede Anforderung aus, die gesendet und für die eine Antwort erstellt wird.
Alle diese Muster gelten bis auf wenige Ausnahmen in der Regel auch für Enterprise-Service-Bus-Technologien. ESBs konzentrieren sich in der Regel mehr auf die synchrone Nachrichtenübermittlung, bei der eine Änderung in einem Teil des Systems (etwa wenn ein neuer Datensatz hinzugefügt oder eine Aktualisierung vorgenommen wird) dazu führt, dass die Änderung an den ESB weitergegeben wird. Dieser transformiert die Nachricht dann und leitet sie an andere Systeme weiter, um sie zu synchronisieren. In gewisser Weise handelt es sich beim API-Management eher um eine Abfrage- und Abstimmungsmethode, bei der ESBs häufiger die Nachrichtenübermittlung priorisieren und Pub-Sub-Muster oder andere ähnliche Ansätze einführen.
API-Management kann mit ArcGIS in vielen verschiedenen Mustern verwendet werden. Im Allgemeinen ist das API-Management am besten geeignet für Anwendungsfälle, in denen es “vor” ArcGIS Server-basierten Services wie Karten-, Feature- oder Geoverarbeitungsservices bereitgestellt wird, in Szenarios, in denen diese Services entweder für ein anderes Unternehmenssystem oder für einen Entwickler- oder End-Client mit einer angepassten Anwendung verfügbar gemacht werden müssen. Zu den wichtigsten Überlegungen zur Arbeit mit dem API-Management gehören:
Beispiel:
/arcgis/rest/services/ServiceName/MapServer/arcgis/rest/services/ServiceName/MapServer/exportImage/arcgis/rest/services/ServiceName/MapServer/0/query/arcgis/rest/services/ServiceName/MapServer/1/queryDas API-Management wird immer beliebter, wenn es darum geht, Integrationsoptionen zwischen Unternehmenssystemen bereitzustellen. Viele Organisationen investieren in Richtlinien oder erstellen diese, um sicherzustellen, dass alle internen Transaktionen von einem API-Managementsystem vermittelt werden, oder setzen die Verwendung des API-Management voraus, um extern zugängliche Services zu erstellen. Beachten Sie im Zusammenhang mit der Systemintegration die folgenden Best Practices:
Das API-Management umfasst per Definition keine Authentifizierungsschicht. Viele Organisationen möchten jedoch eine Authentifizierung auf ihre API Management-Endpunkte anwenden, um die Benutzerüberprüfung und Autorisierungsverwaltung sicherzustellen. Zu den gängigen Authentifizierungsmethoden für das API-Management gehören die Verwendung eines API- oder Abonnementschlüssels sowie die Integration mit OAuth-basierten Authentifizierungsmethoden in einen vorhandenen Identity-Provider (IdP). Jedes dieser Muster kann bei ArcGIS-Integrations-Workflows mit Herausforderungen verbunden sein.
Beachten Sie, dass auf API-Management basierende Client-Authentifizierungsmethoden möglicherweise nicht mit standardmäßigen ArcGIS-Clients kompatibel sind. Wenn z. B. das API-Management-System eine headerbasierte Authentifizierung erfordert, bei der entweder ein servicespezifischer Header oder ein Bearer-Autorisierungsheader verwendet wird, können ArcGIS-Standardclients diesen Header nicht dynamisch zu Anforderungen hinzufügen, um den Zugriff auf diesen Service zu unterstützen. In ähnlicher Weise können API-Schlüssel eine gängige Authentifizierungsschicht sein, die über eine API-Management-Schnittstelle hinzugefügt wird. Anwendungsentwickler müssen sich jedoch dieser Anforderung bewusst sein und in der Lage sein, sie Anforderungen hinzuzufügen, um diese Services in eine Anwendung zu integrieren. Verschiedene ArcGIS-SDKs und Service-Registrierungsmuster können diese Art von Authentifizierungsmuster für Subskriptionsschlüssel oder API-Schlüssel unterstützen, sollten jedoch sorgfältig getestet werden, bevor davon ausgegangen wird, dass ein Authentifizierungsmuster geeignet ist.
Die OAuth-basierte Authentifizierung im API-Management bringt weitere Herausforderungen mit sich. Beim Entwickeln einer benutzerdefinierten Anwendung mit einem unterstützten SDK kann es relativ einfach sein, eine anfängliche Umleitung an den OAuth-Service bereitzustellen, ein Token oder einen Code zurückzugeben und das Token an weitere Anforderungen in dieser Sitzung anzuhängen. Bei Verwendung einer standardmäßigen ArcGIS-Anwendung ist diese Konfiguration jedoch viel komplizierter in der Anwendung, da diese Clients einen direkten Zugriff auf ArcGIS-Geo-Services erwarten, ohne dass zusätzliche Authentifizierungsschritte erforderlich sind, die nicht von ArcGIS verwaltet werden.
Im Allgemeinen bietet die Verwendung von API- oder Abonnementschlüsseln in diesem Zusammenhang den erfolgreichsten Integrationspfad, wobei die folgenden Empfehlungen beachtet werden sollten: