stokkete - stock.adobe.com
Interne und externe APIs richtig managen
Interne und externe APIs unterscheiden sich technisch zwar kaum, doch gibt es wichtige Unterschiede bei Fragen des API-Designs und -Lifecycle-Managements.
Interne und externe APIs erfüllen beide die gleiche grundlegende Funktion: die Bereitstellung von Daten und Integrationen, die den Betrieb von Anwendungen erleichtern. Je nachdem, ob sie mit internen APIs arbeiten, müssen Architekten und Entwickler jedoch die Art und Weise anpassen, wie sie diese APIs überwachen und verwalten. Andernfalls kann dies drastische Auswirkungen auf die Nutzbarkeit der APIs haben – und möglicherweise zu Datenverlusten führen.
In diesem Artikel gehen wir darauf ein, was eine interne und was eine externe API genau ausmacht. Anschließend stellen wir sechs spezifische Bereiche des API-Managements vor, in denen jeder Typ einen etwas anderen Ansatz erfordert.
Was ist eine interne API?
Interne APIs ermöglichen den Zugriff auf sensible Ressourcen innerhalb des Softwaresystems eines Unternehmens. Sie vereinfachen den Prozess der Verknüpfung von Backend-Systemen oder Daten mit der Vielzahl von Anwendungen, die interne Abläufe steuern.
Jede Anwendung kann eine standardisierte interne API verwenden, um sich in ein internes System zu integrieren. Dadurch entfällt die Notwendigkeit, individuelle Integrationen zwischen den einzelnen Anwendungen zu erstellen oder Verbindungen zwischen Backend-Systemen manuell herzustellen.
Was ist eine externe API?
Externe APIs machen die internen Ressourcen eines Unternehmens für externe Benutzer oder Anwendungen zugänglich. Beispielsweise können Drittentwickler, die auf Daten oder Dienste eines Unternehmens zugreifen müssen, dies mit externen APIs erreichen. Dies gilt ebenso für Entwickler, die Apps erstellen möchten, welche sich in die Plattform des Unternehmens integrieren sollen.
Trotz des Namens können einige Teams bestimmte externe APIs auch intern verwenden, zum Beispiel zur Verwaltung bestimmter Integrationen zwischen internen Anwendungen und Backend-Systemen. Im Gegensatz zu internen APIs sind externe APIs jedoch nicht auf die Verwendung innerhalb des Unternehmens beschränkt. Sie sollten deshalb sorgfältig konzipiert, gesichert und überwacht werden. Ansonsten besteht die Gefahr, dass sensible Geschäftsdaten nach außen gelangen.
Internes versus externes API-Management
In Bezug auf das technische Design und die Kernfunktionalität arbeiten interne und externe APIs grundsätzlich auf die gleiche Art und Weise. Entwickler können API-Designs wie REST, SOAP oder GraphQL verwenden, um beide Arten von APIs zu erstellen. Ebenso sind die Prozesse der Datenanforderung und des Teilens von Daten bei beiden ähnlich.
Wenn es jedoch um das API-Management geht, müssen Entwicklungs- und Managementteams interne und externe APIs unterschiedlich behandeln. Die sechs Hauptbereiche, in denen sich die Managementdetails für interne und externe APIs unterscheiden, sind:
- APIs veröffentlichen und finden
- API-Sicherheit und -Zugriffskontrolle
- API-Richtlinien durchsetzen
- API-Leistung testen
- APIs überwachen und tracken
- APIs ausmustern und auslaufen lassen
APIs veröffentlichen und finden
Die Veröffentlichung und das Finden von APIs hilft Entwicklern, APIs zu finden, damit sie diese in ihre Anwendungen integrieren können. Grundsätzlich sollten APIs auffindbar sein, unabhängig davon, ob es sich um interne oder externe APIs handelt. Jedoch kann der tatsächliche Veröffentlichungsprozess, der eine API auffindbar macht, variieren.
Wenn es sich um externe APIs handelt, sollte man diese so veröffentlichen, dass sie für jeden Entwickler leicht zu finden und schnell zu verstehen sind – selbst für diejenigen, die nur wenig über das individuelle technische Ökosystem des Unternehmens wissen. Bei internen APIs hingegen sollten Sie mehr darüber wissen und spezifische Fähigkeiten oder Funktionen kennen.
Entwickler, die auf interne APIs setzen, suchen und finden diese APIs in der Regel von sich aus. Bei externen APIs hingegen konkurriert das Unternehmen oft mit anderen Unternehmen, um die Aufmerksamkeit der Entwickler zu gewinnen und sie zur Nutzung seiner APIs zu bewegen. Daher muss das Entwicklungsteam bei der Veröffentlichung und dem Finden von APIs ähnlich wie Marketingexperten vorgehen.
API-Sicherheit und -Zugriffskontrolle
Die Tatsache, dass sich interne APIs in internen Systemen befinden, macht es nicht überflüssig, sie zu sichern. Die interne Nutzung vereinfacht jedoch die API-Sicherheit, da interne APIs weniger Bedrohungen ausgesetzt sind, die außerhalb Ihres Unternehmens existieren. Wenn Ihnen nur begrenzte Ressourcen für die API-Sicherheit zur Verfügung stehen, sollten Sie den Großteil davon in die Sicherung externer APIs investieren.
Die Zugriffskontrollen für externe APIs sind oft nicht sehr granular. Ein Unternehmen möchte in der Regel, dass alle internen und externen Entwickler diese externen APIs nutzen können. Dadurch wird die Notwendigkeit zur Feinabstimmung verringert, wer was mit ihnen machen kann. Interne APIs können jedoch komplexere Zugriffskontrollen erfordern, um sicherzustellen, dass nur berechtigte Interessengruppen innerhalb Ihres Unternehmens die APIs verwenden können.
Die meisten Anbieter von API-Management-Tools, die Funktionen für Unternehmen bieten, wie zum Beispiel Nginxund RapidAPI, enthalten Maßnahmen für die interne und externe API-Sicherheit in einem Paket. Das Entwicklungsteam muss jedoch immer noch sicherstellen, dass diese APIs identifiziert und entsprechend gesichert werden.
API-Richtlinien durchsetzen
API-Richtlinien spielen eine entscheidende Rolle bei der Kontrolle, wie interne und externe Entwickler mit dieser API arbeiten können und was sie damit tun können. Eine Richtlinie kann zum Beispiel die Anzahl der Anfragen begrenzen, die eine Anwendung innerhalb eines bestimmten Zeitraums an eine API stellen kann. Diese Art des Richtlinienmanagements ist aus Performance-Sicht wichtig – und verhindert den Missbrauch der API durch böswillige Akteure.
Wie bei der API-Sicherheit ist die Durchsetzung von Richtlinien für externe APIs am wichtigsten. Bei diesen ist die Wahrscheinlichkeit eines Missbrauchs größer. Aber auch für interne APIs sind Richtlinien erforderlich. Diese müssen sicherstellen, dass alle internen Entwickler und Systeme gleichen Zugang zu den API-Ressourcen haben. Die Richtlinien müssen auch verhindern, dass es zu Noisy-Neighbor-Problemen kommt: Wenn mehrere Anwendungen oder Entwickler dieselbe interne API nutzen wollen, kommt es schnell zu einer Überlastung von Ressourcen.
API-Leistung testen
Sowohl interne als auch externe APIs müssen getestet werden – beide erfordern jedoch jeweils eigene Testarten. Der Grund dafür ist, dass die Anwendungsfälle oder Anforderungsmuster für externe APIs wahrscheinlich breiter gefächert sind als für die meisten internen APIs.
Bei internen APIs können Entwickler Leistungstests auf der Grundlage der spezifischen API-Anwendungsfälle durchführen, die das Unternehmen unterstützen muss. In der Regel sind diese Fälle gut dokumentiert. Im Gegensatz dazu lässt sich nur schwer vorhersagen, wie Entwickler außerhalb des Unternehmens eine externe API einsetzen werden. Diese Unklarheit macht eine breitere Testabdeckung erforderlich.
Eine Strategie, dieses Problem in den Griff zu bekommen, besteht darin, Mock APIs zu erstellen. Mock APIs sind in der Lage, so viele potenzielle Anwendungsfälle wie möglich zu simulieren. Die Fähigkeit, dies zuverlässig zu tun, hängt jedoch davon ab, wie genau die Entwickler die API nachbilden und das Benutzerverhalten vorhersagen können.
APIs überwachen und tracken
Im Gegensatz zu den eben präsentierten Managementaspekten gibt es bei der API-Überwachung und -Leistungsverfolgung keine großen Unterschiede zwischen internen und externen APIs. Jede API, die für Produktionszwecke verwendet wird – ob von internen oder externen Benutzern – erfordert eine sorgfältige Überwachung von Ausfällen und Leistungseinbußen.
Allerdings gibt es einige Möglichkeiten, wie Entwickler die Überwachung auf das eine oder andere kalibrieren können. Bei internen APIs können Entwickler in der Regel so viele Daten über die API-Leistung sammeln, wie sie möchten. Schließlich können sie sowohl den API-Server als auch die Client-Komponenten problemlos beobachten. Bei externen APIs hingegen sind Entwickler möglicherweise auf die vom Server verfügbaren Metriken beschränkt – es sei denn, sie haben direkten Zugriff auf die Clients oder können die Request-Response-Verfahren genau nachbilden.
APIs ausmustern und auslaufen lassen
Wenn eine API die Grenzen ihrer Nutzbarkeit erreicht hat, ist es oft einfacher, interne APIs auszumustern und auslaufen (sunsetting) zu lassen als externe APIs. Bei internen APIs ist es in der Regel möglich, alle Beteiligten innerhalb weniger Wochen vor der Stilllegung zu informieren. Sollten diese Anwender über das Ende der Verfügbarkeit der API unglücklich sein, ist es einfacher, die Gründe für die Einstellung der API zu erklären und gegebenenfalls einen brauchbaren Ersatz bereitzustellen.
Bei externen APIs müssen Entwickler sorgfältiger vorgehen. Um einen schlechten Ruf in der Entwicklergemeinschaft zu vermeiden, sollten Unternehmen die Einstellung von APIs lange im Voraus ankündigen. Lange im Voraus heißt hier: Monate oder gar Jahre vor der Abschaltung.
Auch die Unterstützung der Entwickler bei der Umstellung auf eine alternative API – falls es eine gibt – ist bei externen APIs mit viel mehr Arbeit verbunden. Wenn es keine Alternative gibt, sollte die Organisation den Entwicklern, die auf diese API angewiesen sind, zumindest einige Ratschläge für die nächsten Schritte geben und sie informieren, was Sie machen können.
