Arten von APIs und Ermittlung der passenden API

Application Programming Interfaces – oder kurz APIs – geben Daten frei und ermöglichen Unternehmen, Systeme, Anwendungen, Geräte und Datensätze miteinander zu verbinden. Es ist wichtig zu verstehen, welche Art von API am besten für ein Projekt geeignet ist. Dafür spielen die folgenden Faktoren eine Rolle: der jeweilige Anwendungsfall, die Personen, die diese APIs verwenden und darauf zugreifen, sowie die Systeme und Datensätze, die miteinander verbunden werden sollen. Eine effektive Leistung der APIs und ein effektives API-Management erzielen Sie nur dann, wenn Sie zunächst die optimale Art von API ermitteln und anschließend die Architektur entsprechend entwerfen und erstellen.

Nur sehr selten entscheiden Unternehmen aus heiterem Himmel, dass sie eine API benötigen. In den meisten Fällen kommen in Unternehmen Ideen, Anwendungen, Innovationen oder Anwendungsfälle auf, die mit anderen Systemen oder Datensätzen verbunden werden müssen.

APIs werden dabei als Mittel für die Herstellung von Konnektivität zwischen den zu integrierenden Systemen und Datensätzen verwendet.

Unternehmen können verschiedene Arten von APIs für unterschiedliche Zwecke verwenden: von der internen Freigabe der Funktionen eines Kernsystems bis hin zur Befähigung kundenseitiger Apps für Mobilgeräte. API-led Connectivity von MuleSoft umfasst drei Kategorien von APIs:

• System-APIs: System-APIs geben Daten aus Kerndatenbanksystemen in einem Unternehmen frei. Beispiele für geschäftskritische Systeme, in denen APIs Daten freigeben könnten: ERP, Kunden- und Abrechnungssysteme sowie proprietäre Datenbanken.
• Prozess-APIs: Prozess-APIs nutzen und definieren Daten in einem einzelnen System oder in mehreren Systemen und lösen Datensilos auf. Prozess-APIs dienen dazu, Daten zu kombinieren. Dabei können mehrere System-APIs zu einem bestimmten Geschäftszweck gemeinsam eingesetzt werden. Beispiele: Erstellung einer 360-Grad-Ansicht des Kunden, Auftragsabwicklung und Lieferstatus.
• Experience-APIs: Experience-APIs stellen einen Geschäftskontext für die Daten und Prozesse bereit, die mit System- und Prozess-APIs freigegeben und festgelegt wurden. Experience-APIs geben die Daten gemäß den Anforderungen der jeweiligen Zielgruppe frei – zum Beispiel Anwendungen für Mobilgeräte und interne Portals für Kundendaten.

Nachdem Sie den Anwendungsfall für die APIs in Ihrem Unternehmen ermittelt haben, müssen Sie festlegen, welche Mitarbeiter auf diese APIs zugreifen werden. In den meisten Fällen gibt es einen logischen Zusammenhang zwischen Anwendungsfall und Zielgruppe. Wenn Sie zum Beispiel Kundendaten für Ihre internen Mitarbeiter im Vertrieb und im Kundenservice freischalten möchten, sind interne Mitarbeiter die Endbenutzer.

Die Kategorien der folgenden drei Arten von APIs sind nach der Art ihrer Verwaltung und ihrer Endbenutzer eingeteilt:

External APIs can be accessed by third-parties (developers, partners, etc.) that are external to the organization. They often make an organization's data and services easily accessible on a self-service basis by developers around the world who are looking to create innovative applications and integrations.

An example of an open API is the Google Maps API that is used across third-party applications (such as ridesharing and food delivery apps) to enable location tracking and mapping.

Internal APIs are the opposite of open APIs in that they are inaccessible to external consumers and only available to an organization’s internal developers. Internal APIs can enable enterprise-wide initiatives from the adoption of DevOps and microservice architectures to legacy modernization and digital transformation. The use and reuse of these APIs can enhance an organization's productivity, efficiency, and agility.

An example of a reusable internal API is if a call center team created a customer information API used in a call center application to access their name, contact information, account info, etc. That team can then reuse this same API in a customer-facing web application or mobile application.

Partner-APIs sind gewissermaßen eine Mischung aus internen und externen APIs. Auf Partner-APIs können unternehmensexterne Benutzer zugreifen, die über exklusive Berechtigungen verfügen. Dieser Sonderzugriff wird in der Regel bestimmten Dritten gewährt, um eine strategische Partnerschaft zu ermöglichen.

Eine Partner-API wird häufig dann angewendet, wenn zwei Unternehmen Daten miteinander austauschen möchten – zum Beispiel ein für das Gesundheitswesen zuständiges Landesministerium und ein Krankenhaus in demselben Bundesland. Eine Partner-API würde so eingerichtet, dass beide Organisationen mit entsprechenden Anmeldedaten und Berechtigungen auf die notwendigen Daten zugreifen können.

Eine weitere Wahl, die Sie hinsichtlich einer API treffen müssen, betrifft die Architekturstile. Es ist äußerst wichtig, dass Sie einen Architekturstil oder ein Architekturmuster wählen, das den Verwendungszweck der API optimal unterstützt, wenn bestimmte Funktionen notwendig sind. Diese Entscheidung bezieht sich auf das API-Design und wird in der Regel von technischen Teams getroffen.

Bevor Sie diese Entscheidung treffen, benötigen Sie einen Überblick über die vorhandene Infrastruktur. Dabei müssen Sie zum Beispiel darauf achten, ob die vorhandenen Systeme lokal installiert oder cloudbasiert sind, welche Systeme und Datensätze verwendet werden sollen, welche Sicherheitsprotokolle zu implementieren und welche Funktionen erforderlich sind. Im Sinne des „API-first“-Prinzips sollten Funktionen und Benutzererfahrungen die Grundlage für Änderungen an Legacy-IT-Systemen bilden, anstatt dass der Zustand der Legacy-IT-Systeme für Funktionen und Benutzererfahrungen ausschlaggebend ist.

Für APIs gibt es verschiedene Architekturstile mit unterschiedlichen Datenformaten. In der folgenden Liste sind einige der gängigsten Architekturstile aufgeführt:

• REST: REST (Representational State Transfer) ist ein Architekturstil, bei dem die Anliegen des API-Nutzers von denen des API-Anbieters getrennt werden. Dies erfolgt über Befehle, die in das zugrunde liegende Netzwerkprotokoll integriert sind. Clients verwenden die enthaltenen Links und Formulare, um Maßnahmen durchzuführen (zum Beispiel Lesen, Aktualisieren, Freigeben, Genehmigen). HTML ist das bekannteste Beispiel für diesen Stil, und es gibt mehrere andere Formate eigens für APIs (zum Beispiel HAL, CollectionJSON und Siren). Zu den zahlreichen Vorteilen von REST-APIs zählen unter anderem Flexibilität und die Fähigkeit, beliebte Datenformate wie zum Beispiel JSON und XML zu unterstützen.
• RPC: In Verbindung mit Remote Procedure Calls (RPCs) müssen Entwickler in der Regel bestimmte Codeblöcke auf einem anderen System ausführen. Für diesen Remote-Aufruf von Prozeduren auf anderen Systemen müssen Entwickler im Normalfall die Prozedurnamen aufrufen. RPC ist Protokoll-agnostisch. Das bedeutet, dass es von vielen Protokollen unterstützt werden kann, aber die Vorteile der Nutzung nativer Protokollfunktionen, zum Beispiel Caching, verloren gehen. Da nicht standardmäßige Prozedurnamen von einer RPC-API zur nächsten stark zunehmen, entsteht eine engere Kopplung zwischen API-Nutzern und -Anbietern. Dadurch werden Entwickler, die an allen Aspekten eines RPC-gesteuerten API-Ökosystems beteiligt sind, überlastet. RPC-Architekturmuster sind in beliebten API-Technologien wie SOAP, GraphQL und gRPC zu finden.
• Ereignisgesteuert/Streaming: Ereignisgesteuerte APIs, die auch als Echtzeit-, Streaming-, asynchrone oder Push-Architekturen bezeichnet werden, warten nicht erst auf einen Aufruf des API-Benutzers, bevor sie eine Antwort ausgeben. Antworten werden stattdessen durch das Auftreten eines Ereignisses ausgelöst. Diese Services stellen Ereignisse bereit, die Clients abonnieren können, um bei Änderungen der Servicewerte Aktualisierungen zu erhalten. Für diesen Stil gibt einige Varianten, zum Beispiel reaktiv, Publish/Subscribe, Ereignisbenachrichtigung und CQRS.

Dieses API-Muster ist für eine Vielzahl von Ereignissen geeignet. Hier nur einige Beispiele:

• Auf einem Twitter-Konto wird ein neuer Tweet veröffentlicht.
• Die Temperatur auf einem entfernten Thermometer ändert sich.
• Ein Fahrzeug fährt über einen Sensor auf dem Bürgersteig.
• Eine Sicherheitskamera erkennt eine Bewegung in ihrem Messfeld.
• Ein elektronisches Kardiogerät erkennt einen unregelmäßigen Herzschlag.
• Eine Notausgangstür wird geöffnet.
• Ein Rauchmelder erkennt Rauch.

Beim Entwerfen und Verwalten effektiver APIs sind viele Aspekte zu berücksichtigen. Der obige Inhalt gibt einen Überblick über die verschiedenen Entscheidungen, die Unternehmen im Rahmen der Vorbereitung auf das Entwerfen, Implementieren und Verwalten einer API treffen müssen. Weitere Informationen erhalten Sie in unserem Whitepaper zum Thema API-led Connectivity.