Die unterschiedlichen API-Typen und ihre Merkmale

Vier Arten von Web-APIs

APIs sind weithin akzeptiert und werden in Webanwendungen verwendet. Es gibt vier Haupttypen von APIs, die üblicherweise in webbasierten Anwendungen verwendet werden: öffentlich, Partner, privat und zusammengesetzt. In diesem Zusammenhang gibt der API-Typ den beabsichtigten Anwendungsbereich an.

Public APIs. Eine Public API ist offen und kann von jedem externen Entwickler oder Unternehmen genutzt werden. Ein Unternehmen, das eine Geschäftsstrategie verfolgt, die die gemeinsame Nutzung seiner Anwendungen und Daten mit anderen Unternehmen vorsieht, wird eine öffentliche API entwickeln und anbieten.

Public APIs erfordern in der Regel eine moderate Authentifizierung und Autorisierung. Ein Unternehmen kann auch versuchen, die API zu monetarisieren, indem es für die Nutzung der Public API eine Gebühr pro Aufruf erhebt.

Partner-APIs. Eine Partner-API, die nur speziell ausgewählten und autorisierten externen Entwicklern oder API-Kunden zur Verfügung steht, ist ein Mittel zur Erleichterung von Business-to-Business-Aktivitäten. Wenn ein Unternehmen beispielsweise seine Kundendaten selektiv mit externen CRM-Firmen teilen möchte, kann eine Partner-API das interne Kundendatensystem mit diesen externen Parteien verbinden - eine andere API-Nutzung ist nicht gestattet.

Partner haben klare Rechte und Lizenzen für den Zugriff auf solche APIs. Aus diesem Grund verfügen Partner-APIs in der Regel über strengere Authentifizierungs-, Autorisierungs- und Sicherheitsmechanismen. Unternehmen machen solche APIs in der Regel auch nicht direkt zu Geld; die Partner werden für ihre Dienste und nicht über die API-Nutzung bezahlt.

Interne APIs. Eine interne (oder private) API ist nur für die Verwendung innerhalb des Unternehmens vorgesehen, um Systeme und Daten innerhalb des Unternehmens zu verbinden. Eine interne API kann zum Beispiel die Gehaltsabrechnungs- und HR-Systeme eines Unternehmens verbinden.

Interne APIs weisen traditionell eine schwache oder gar keine Sicherheit und Authentifizierung auf, da die APIs für den internen Gebrauch bestimmt sind und derartige Sicherheitsstufen durch andere Richtlinien als gegeben vorausgesetzt werden. Dies ändert sich jedoch, da ein größeres Bewusstsein für Bedrohungen und Anforderungen zur Einhaltung von Vorschriften die API-Strategie eines Unternehmens zunehmend beeinflussen.

Composite APIs. Composite (zusammengesetzte) APIs kombinieren im Allgemeinen zwei oder mehr APIs, um eine Abfolge von verwandten oder voneinander abhängigen Vorgängen zu erstellen. Diese APIs können vorteilhaft sein, um komplexe oder eng miteinander verbundene API-Verhaltensweisen zu adressieren, und können manchmal die Geschwindigkeit und Leistung gegenüber einzelnen APIs verbessern.

API-Protokolle und -Architekturen

APIs tauschen Befehle und Daten aus, und dies erfordert klare Protokolle und Architekturen: das sind die Regeln, Strukturen und Einschränkungen, die den Betrieb einer API bestimmen. Es gibt drei Kategorien von API-Protokollen oder -Architekturen: REST, RPC und SOAP. Diese können als Formate bezeichnet werden, die jeweils einzigartige Merkmale und Kompromisse aufweisen und für unterschiedliche Zwecke eingesetzt werden.

REST. Die REST-Architektur (Representational State Transfer) ist vielleicht der beliebteste Ansatz für die Erstellung von APIs. REST basiert auf einem Client/Server-Ansatz, der die vorderen und hinteren Enden der API voneinander trennt und erhebliche Flexibilität bei der Entwicklung und Implementierung bietet. REST ist zustandslos (stateless), was bedeutet, dass die API keine Daten oder keinen Status zwischen den Anfragen speichert. REST unterstützt die Zwischenspeicherung von Antworten für langsame oder nicht zeitempfindliche APIs. REST-APIs, in der Regel als RESTful APIs bezeichnet, können auch direkt kommunizieren oder über Zwischensysteme wie API-Gateways und Load Balancer arbeiten.

RPC. Das RPC-Protokoll (Remote Procedural Call) ist ein einfaches Mittel, um mehrere Parameter zu senden und Ergebnisse zu empfangen. RPC-APIs rufen ausführbare Aktionen oder Prozesse auf, während REST-APIs hauptsächlich Daten oder Ressourcen wie Dokumente austauschen. RPC kann zwei verschiedene Sprachen, JSON und XML, für die Kodierung verwenden; diese APIs werden JSON-RPC beziehhungsweise XML-RPC genannt.

SOAP. Das Simple Object Access Protocol (SOAP) ist ein Messaging-Standard, der vom World Wide Web Consortium definiert wurde und allgemein zur Erstellung von Web-APIs verwendet wird, in der Regel mit XML. SOAP unterstützt eine breite Palette von Kommunikationsprotokollen, die im Internet zu finden sind, wie HTTP, SMTP und TCP. SOAP ist außerdem erweiterbar und stilunabhängig, was es Entwicklern ermöglicht, SOAP-APIs auf unterschiedliche Weise zu schreiben und auf einfache Weise Merkmale und Funktionen hinzuzufügen. Der SOAP-Ansatz legt fest, wie die SOAP-Nachricht verarbeitet wird, welche Funktionen und Module enthalten sind, welche Kommunikationsprotokolle unterstützt werden und wie die SOAP-Nachrichten aufgebaut sind.

Verglichen mit der Flexibilität von REST ist SOAP ein stark strukturierter, streng kontrollierter und klar definierter Standard. SOAP-Nachrichten können beispielsweise bis zu vier Komponenten enthalten, darunter einen Umschlag, einen Header, einen Body und einen Fault (Fehlerbehandlung).

Vergleich von API-Protokollen

Die Wahl eines API-Formats kann einen tiefgreifenden und langfristigen Einfluss auf den Erfolg und die Akzeptanz einer API haben. Unternehmen müssen das am besten geeignete Format auswählen, und zwar auf der Grundlage der Komplexität der auszutauschenden Informationen, des erforderlichen Sicherheitsniveaus für diese Informationen und der Geschwindigkeit oder Leistung, die für diesen Austausch erforderlich ist.

So kann ein einfacheres Format zwar leichter zu programmieren und zu pflegen sein, bietet aber möglicherweise nicht das Maß an Sicherheit, wie zum Beispiel Verschlüsselung, das ein Unternehmen benötigt. Komplexere Formate können diese Sicherheit bieten, stellen aber eine höhere Lernkurve für die Anwender dar oder erfordern mehr Fehlerkorrekturen und Arbeit für die Entwickler. Der Kompromiss ist selten einfach, aber es gibt einige gemeinsame Überlegungen für die wichtigsten API-Formate.

Vergleichen wir REST und SOAP. Beide Formate sind für die Verbindung von Anwendungen konzipiert und verwenden hauptsächlich HTTP-Protokolle und -Befehle wie GET, POST und DELETE. Beide können XML in Anfragen und Antworten verwenden. Allerdings ist SOAP von vornherein auf XML angewiesen, während REST auch JSON, HTML und einfachen Text verwenden kann. SOAP ist mit strengen Regeln standardisiert, während REST flexible Regeln zulässt und stattdessen von Architekturen bestimmt wird. SOAP basiert auf Remote Procedure Calls, während REST auf Ressourcen basiert.

Sowohl REST als auch SOAP tauschen also Informationen aus, allerdings auf sehr unterschiedliche Weise. SOAP wird verwendet, wenn ein Unternehmen strenge Sicherheitsvorkehrungen und klar definierte Regeln zur Unterstützung eines komplexeren Datenaustauschs und die Möglichkeit zum Aufruf von Prozeduren benötigt. Entwickler verwenden SOAP häufig für interne oder Partner-APIs.

REST wird für den schnellen Austausch von relativ einfachen Daten verwendet. REST kann auch eine größere Skalierbarkeit bieten und unterstützt große und aktive Benutzergruppen. Diese Eigenschaften machen REST zu einer beliebten Lösung für Public APIs, zum Beispiel in mobilen Anwendungen.

Die Diskussion darüber, wann RPC verwendet werden sollte, ist etwas einfacher. Ähnlich wie SOAP ist RPC stark strukturiert und für relativ einfache APIs gedacht, die Prozesse aufrufen können. Die Entscheidung, ob JSON oder XML verwendet werden soll, hängt wiederum vom Zweck der API, den auszutauschenden Informationstypen und dem erforderlichen Sicherheitsniveau ab.

JSON ist die einfachere Sprache, und JSON-RPCs unterstützen nur den Austausch von alphanumerischen Daten (Text) mit geringer Sicherheit. XML-RPC kann ein breiteres Spektrum an Daten verarbeiten, darunter Text, Bilder, Grafiken und Diagramme und vieles mehr. Daher bietet XML bessere Möglichkeiten zur Dokumentenverarbeitung und bessere Sicherheitsfunktionen als JSON. Beide Ansätze unterstützen eine Vielzahl von Programmiersprachen, darunter Python, Java und PHP.

Letztlich sind RPC-basierte APIs aufgrund ihrer begrenzten Datentypunterstützung und ihrer eingeschränkten Sicherheit eine schlechte Wahl für APIs auf Unternehmensebene. Sie können jedoch für einige interne zusammengesetzte APIs geeignet sein. JSON-RPC-APIs können beispielsweise Aufrufe tätigen, ohne eine Antwort abzuwarten, und unterstützen mehrere gleichzeitige Aufrufe, die asynchron verarbeitet werden können.