Vergleich von sechs API-Stilen: REST, GraphQL, WebSockets, Webhooks, gRPC, SOAP

Die meisten Menschen wählen REST als ihren ersten API-Stil und betrachten ihn anschließend als universelle Lösung. Das ist er jedoch nicht. REST ist nur eine von sechs Optionen, und die anderen fünf existieren genau deshalb, weil REST in bestimmten Situationen an Grenzen stößt – bei Echtzeit-Updates, schnellen internen Service-zu-Service-Aufrufen, strengen Unternehmenssicherheitsanforderungen sowie flexiblen Datenschemata. Jeder andere API-Stil auf dieser Liste wurde entwickelt, um Probleme zu bewältigen, mit denen REST Schwierigkeiten hat.

Falls REST Ihnen bereits vertraut ist, wird im Folgenden genau erläutert, wann Sie die Tools wechseln sollten und warum.

Was eine API ist (ein Absatz, dann weiter)

In seinem Kern steht eine API zwischen zwei Systemen und ermöglicht es ihnen, miteinander zu kommunizieren. Wenn Sie „Biryani“ in einer Essenslieferungs-App eingeben, liegen die Ergebnisse noch nicht auf Ihrem Telefon. Ihre App sendet eine Anfrage an den Server des Unternehmens, und der Server antwortet mit passenden Daten. Die Regeln, die diesen Austausch steuern – wie die Anfrage gestaltet wird und wie die Antwort aussieht –, bilden die API. Stellen Sie sich einen Kellner in einem Restaurant vor: Sie gehen niemals selbst in die Küche, um sich das Essen zu holen; Sie sagen dem Kellner, was Sie möchten, und der Kellner kümmert sich um den Rest. Dieser Kellner ist im Grunde genommen die API.

Es gibt tatsächlich sechs verschiedene Arten von „Kellnern“, auf die man stoßen kann.

REST: Der Standard und seine Grenzen

REST, abgekürzt für Representational State Transfer, basiert auf HTTP und stützt sich auf zwei zentrale Konzepte: eine URL, die die gewünschte Ressource identifiziert, sowie eine HTTP-Methode, die die zu ausführende Aktion beschreibt.

Vier Methoden decken fast alles ab: GET holt Daten ab, POST erstellt ein neues Datensatz, PUT aktualisiert oder ersetzt einen bestehenden Datensatz und DELETE löscht ihn. Ein wesentliches Merkmal von REST ist die Zustandslosigkeit – der Server speichert keine Erinnerung an frühere Interaktionen mit Ihnen. Jeder benötigte Kontext muss jedes Mal in der Anfrage selbst enthalten sein.

GET https://api.zomato.com/v1/restaurants?search=biryani
Authorization: Bearer <token>

Sobald die Anfrage eingegangen ist, überprüft der Server, wer Sie sind, holt die relevanten Datensätze aus der Datenbank und sendet einen JSON-Inhalt zurück.

Wo es passt: öffentlich zugängliche APIs, Standard-Apps für Erstellen, Lesen, Aktualisieren und Löschen sowie alle Szenarien, in denen Client und Server klar voneinander getrennt sind und ein vorhersehbares, gut dokumentiertes Vertragswerk benötigen. REST hat seinen Standardstatus aus gutem Grund erlangt – es ist einfach, erfordert nicht, dass der Server den Sitzungszustand verfolgt, ist weithin verstanden und basiert auf herkömmlichem HTTP.

Wo es nachlässt: alles, was Echtzeit-Updates erfordert (Chat-Apps, Live-Ortung), Fälle, in denen ein einziger Bildschirm Daten aus mehreren verschiedenen Ressourcen gleichzeitig abrufen muss, oder interne Servicekommunikationen, bei denen reine Geschwindigkeit wichtiger ist als Lesbarkeit für Menschen.

GraphQL: Fordern Sie genau das, was Sie benötigen

REST weist ein bekanntes Problem auf: das Überabrufen von Daten. Wenn man einen /user-Endpunkt aufruft, kann man Namen, Profilfoto, Alter, Abteilung, Gehalt sowie Dutzende weiterer Felder erhalten – obwohl man eigentlich nur den Namen und das Foto haben wollte. Die Gegenrichtung ist das Unterabrufen, bei dem eine einzige Ansicht Teile aus mehreren Ressourcen benötigt, wodurch man mehrere REST-Aufrufe tätigen und die Ergebnisse auf der Client-Seite zusammenfügen muss.

GraphQL löst beide Probleme auf einmal: Ein einziger Endpunkt in Kombination mit einer Abfragesprache, die es dem Client ermöglicht, genau anzugeben, welche Felder er zurückhaben möchte.

# Instead of hitting /employees/123 and getting everything,
# you describe precisely what you need in the request body
query {
  employee(id: "123") {
    name
    photo
  }
}

Die Antwort enthält nur die beiden angeforderten Felder – nichts Zusätzliches. Braucht man auch das Gehalt? Fügt es einfach zur Abfrage hinzu. Es ist nicht notwendig, dafür einen separaten Endpunkt einzurichten.

GraphQL unterstützt drei Arten von Operationen. Eine Abfrage liest Daten und erfüllt dabei dieselbe Funktion wie ein REST GET. Eine Mutation schreibt oder ändert Daten und entspricht somit einer Kombination aus POST, PUT und DELETE. Eine Abonnierung öffnet einen Echtzeit-Datenfluss für kontinuierliche Aktualisierungen und funktioniert ähnlich wie WebSockets.

Anwendungsgebiete: funktionale Frontends, die flexible Datenschemata benötigen, Mobile-Apps, bei denen eine Minimierung der Payload-Größe wichtig ist, sowie alle Situationen, in denen mehrere Client-Typen – Web, Mobilgeräte, Drittanbieter-Integrationen – auf denselben Backend-Zugriff haben, aber jeweils nur einen bestimmten Datenteil benötigen.

Wo es nachlässt: grundlegende CRUD-Dienste, bei denen die einfachen Endpunkte von REST bereits gut genug funktionieren. GraphQL bringt echte Komplexität auf der Serverseite mit sich, das Caching wird deutlich schwieriger als bei REST, und es handelt sich oft um unnötigen Overhead, wenn die Anforderungen an die Daten stabil und klar definiert sind.

WebSockets: Die dauerhafte Verbindung

Echtzeitfunktionen offenbaren eine grundlegende Schwäche bei REST. Um herauszufinden, ob gerade eine neue Chatnachricht eingetroffen ist, müsste ein auf REST basierender Client ständig abfragen: „Ist etwas Neues da?“, immer wieder. Multipliziert man das mit einer Million gleichzeitigen Benutzern, erhält man eine Million Anfragen pro Sekunde, von denen die überwiegende Mehrheit mit „Nein“ antwortet – reiner, verschwendeter Overhead.

WebSockets umgehen dieses Problem vollständig, indem sie das Anfrage-Antwort-Muster durch eine dauerhafte, zweckrichtige Verbindung ersetzen. Sie beginnen als gewöhnliche HTTP-Anfrage, doch diese enthält ein spezielles Upgrade-Header:

GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade

Sobald der Server zustimmt, verwandelt sich diese HTTP-Verbindung in eine WebSocket-Verbindung. Von da an kann jede Seite jederzeit eine Nachricht an die andere senden, ohne vorherige Genehmigung erforderlich zu sein. Der Kanal bleibt offen, bis eine der Parteien ihn absichtlich schließt.

Eine WebSocket-Verbindung durchläuft vier unterschiedliche Zustände: Connecting (die Verbindungsherstellung ist im Gange), Open (Nachrichten fließen in beide Richtungen), Closing (der Abbruch hat begonnen) und Closed (die Verbindung existiert nicht mehr). Der Versuch, Daten über eine bereits geschlossene Verbindung zu senden, führt zum Absturz des Servers – ein Fehler, dem Anfänger oft begegnen.

Anwendungsgebiete: Live-Chat, Mehrspieler-Spiele, Tools zur Echtzeit-Kollaboration wie gemeinsam genutzte Dokumente, Live-Sportergebnisse sowie Push-Benachrichtigungen – im Grunde jede Situation, in der der Server ohne Aufforderung Daten senden muss.

Wo sie nachlassen: bei der gewöhnlichen Datenabrufung, bei der der Client Informationen nur dann benötigt, wenn er explizit darum bittet. Da WebSockets die Verbindungen kontinuierlich offen halten, verbrauchen sie Serverressourcen. Ihre Einsetzung dort, wo einfaches REST ausreichen würde, führt lediglich zu unnötigem Ressourcenverbrauch ohne Vorteil.

Webhooks: Der Server ruft Sie an

Sowohl REST als auch WebSockets beginnen beim Client. Der Client öffnet die Verbindung, sendet den Anfrage und der Server antwortet. Webhooks kehren diesen Ablauf völlig um – anstatt Sie um Aktualisierungen vom Server zu bitten, kontaktiert dieser Sie sofort, sobald etwas Wichtiges passiert.

Die Mechanik ist einfach. Man registriert eine URL bei einem Drittanbieterdienst und gibt an, was mit dieser URL geschehen soll – beispielsweise „Sobald eine Zahlung abgeschlossen ist, senden Sie hier einen POST-Anfrage.“ Sobald die Zahlung tatsächlich abgeschlossen wird, sendet der Zahlungsanbieter – egal ob Razorpay, Stripe oder ein anderer – automatisch eine Anfrage an Ihren Endpunkt. Es gibt keinen Polling-Loop und keine Notwendigkeit, die Verbindung ständig zu überwachen. Man muss lediglich abwarten, bis der Aufruf eintrifft.

# What you give Razorpay in setup:
Webhook URL: https://yourapp.com/webhooks/payment

# What Razorpay sends when payment completes:
POST https://yourapp.com/webhooks/payment
{
  "event": "payment.captured",
  "payload": { "amount": 50000, "order_id": "order_abc" },
  "signature": "sha256_hash_here"
}

Die Signaturüberprüfung ist hier nicht optional – sie stellt das gesamte Sicherheitsnetz dar. Ihr webhook-Endpunkt ist öffentlich erreichbar, was bedeutet, dass theoretisch jeder ein gefälschtes „payment.captured“-Event senden und Ihr System dazu bringen könnte, eine Bestellung freizugeben, für die eigentlich nie bezahlt wurde. Die in der Payload enthaltene Signatur ist ein kryptografischer Hash, der nachweist, dass die Anfrage tatsächlich vom Anbieter stammt. Ihr Server muss diese Signatur überprüfen, bevor er auf etwas im Anfragekörper reagiert.

Wann es verwendet werden sollte: bei Zahlungskonfirmationen, Änderungen des Bestellstatus, CI/CD-Pipelines (GitHub informiert Ihren Server, sobald neuer Code eingereicht wird) sowie im Allgemeinen in jedem Workflow, bei dem Sie auf ein Ereignis reagieren, das in einem externen System stattgefunden hat.

Wann man es nicht verwenden sollte: bei jeder Anwendung, die eine sofortige Antwort innerhalb derselben Interaktion erfordert. Webhooks arbeiten nachträglich – sie sind von Natur aus asynchron. Wenn ein Benutzer gerade vor dem Bildschirm sitzt und auf Bestätigung wartet, ist REST weiterhin die bessere Wahl.

gRPC: Binärgeschwindigkeit für interne Dienste

Eine umfangreiche Anwendung besteht selten aus einem einzigen Server. Eine Plattform wie Zomato beispielsweise betreibt separate Dienste für Bestellungen, Zahlungen, Benachrichtigungen und Restaurantdaten, wobei diese Dienste tausende Male pro Sekunde miteinander kommunizieren. Wenn all dieser interne Austausch über REST abgewickelt wird, muss ständig JSON serialisiert und deserialisiert werden. Die Lesbarkeit von JSON ist hervorragend für Entwickler, die sich Logs ansehen, doch genau diese Lesbarkeit bringt bei hohen Datenmengen erhebliche Verarbeitungskosten mit sich.

gRPC, ursprünglich von Google entwickelt, um den eigenen internen Datenverkehr zu verarbeiten, ersetzt JSON durch Protocol Buffers (Protobuf) – ein binäres Format, das deutlich kompakter ist und sich schneller kodieren sowie decodieren lässt. Derselbe Datenträger, den REST als lesbaren Text überträgt, wird von gRPC als dichter binärer Blob gesendet, den Maschinen viel schneller verarbeiten können.

// You define your data structure once in a .proto file
message OrderRequest {
  string order_id = 1;
  string user_id = 2;
  float amount = 3;
}

Der Leistungszuwachs hängt nicht nur vom Datenformat ab. gRPC läuft außerdem auf HTTP/2, was das Multiplexing ermöglicht – Tausende von Anfragen können gleichzeitig über eine gemeinsame Verbindung gesendet werden, im Gegensatz zu HTTP/1.1, das sie nacheinander verarbeitet. Darüber hinaus bietet gRPC vier unterschiedliche Kommunikationsmuster: Unary (eine einzige Anfrage gepaart mit einer einzigen Antwort, im selben Format wie REST), Server Streaming (eine Anfrage, die einen Strom von Antworten auslöst – nützlich beispielsweise für das Echtzeit-Tracking von Bestellungen), Client Streaming (mehrere Anfragen, die zu einer einzigen Endantwort zusammengefasst werden – geeignet zum Hochladen eines Files in Teilen) sowie Bidirectional Streaming (beide Seiten streamen kontinuierlich zueinander – geeignet für Echtzeit-Kollaborationsfunktionen).

Wann es verwendet werden sollte: für Dienst-zu-Dienst-Verbindungen innerhalb der eigenen Infrastruktur, wo Geschwindigkeit und strenge Typisierung entscheidend sind. Überall dort, wo Ihre Dienste große Mengen an Anfragen austauschen und die JSON-Parseung zu einem messbaren Kostenfaktor wird.

Wann es nicht verwendet werden sollte: für öffentliche APIs, die von Browsern oder externen Entwicklern genutzt werden. Aufgrund der binären Natur von Protobuf ist eine Inspektion und Fehlerbehebung deutlich schwieriger, und die Nutzung im Browser erfordert zusätzliche Einrichtungen. Für alle Anwendungen, die für Endnutzer bestimmt sind, bleibt REST die praktischere Wahl.

SOAP: Strenge Struktur, umfangreich, und dennoch in Banken im Einsatz

SOAP (Simple Object Access Protocol) stammt aus dem Jahr 1998 und ist somit älter als REST selbst. Heutzutage stoßen die meisten Entwickler nur dann darauf, wenn sie mit Bankensystemen, Versicherungsplattformen oder großen Unternehmenssoftwarelösungen arbeiten – Branchen, die SOAP früh übernommen haben und nie einen triftigen Grund hatten, darauf zu verzichten.

SOAP ist nicht flexibel. Jede Nachricht ist als XML in einem streng definierten Rahmen verpackt. Während REST viel Freiraum lässt, wie die Daten strukturiert werden, verlangt SOAP, dass beide Seiten sich an ein exakt vorgegebenes Schema halten.

<!-- Every SOAP message follows this envelope structure -->
<Envelope>
  <Header>
    <Security><!-- authentication goes here --></Security>
  </Header>
  <Body>
    <GetAccountBalance>
      <AccountId>ACC123</AccountId>
    </GetAccountBalance>
  </Body>
</Envelope>

Diese aufwändige Struktur existiert absichtlich. Der WS-Security-Standard von SOAP kombiniert Authentifizierung, digitale Signaturen und Verschlüsselung in einer einzigen Nachricht. Bei Finanztransaktionen, bei denen jede Manipulation während der Übertragung echten Schaden verursachen könnte, rechtfertigt diese eingebaute Schutzschicht das zusätzliche Volumen.

Wann es verwendet werden sollte: Bei der Verbindung zu einer Bank-API, einem Zahlungsgateway, das SOAP erfordert, Regierungssystemen, Versicherungsplattformen oder jedem älteren Unternehmenssystem, das nur eine SOAP-Schnittstelle bereitstellt. Es ist unwahrscheinlich, dass man für etwas, das von Grund auf entwickelt wird, SOAP wählt, doch sein Verständnis ist wichtig, wenn man mit darauf basierenden Systemen zusammenarbeiten muss.

Wann es nicht verwendet werden sollte: Bei jedem neuen Projekt, bei dem man beide Endpunkte der Kommunikation kontrolliert. SOAP erfordert mehr Zeit zur Implementierung, seine XML-Datenpakete erschweren das Debuggen, und es bietet im Vergleich zu REST oder gRPC keinen Vorteil, solange keine Kompatibilität mit alten Systemen eine Einschränkung darstellt.

Die Entscheidungsmappe

Nutzen Sie dies als schnellen Überblick zur Auswahl des richtigen Tools:

Eine herkömmliche Webanwendung oder eine öffentlich zugängliche API nutzt REST. Eine Mobile-App, die flexible, an die Anforderungen angepasste Daten benötigt, verwendet GraphQL. Für Live-Chat, Mehrspielerinteraktionen oder Echtzeit-Push-Benachrichtigungen sind WebSockets erforderlich. Zahlungserfassungen sowie Auslösungen von CI/CD-Prozessen benötigen Webhooks. Interne Microservices, die eine hohe Leistungsfähigkeit erfordern, setzen auf gRPC. Bankensysteme und Legacy-Enterprise-Integrationen nutzen SOAP.

Was Sie jetzt verstehen

REST bleibt die Standardwahl. Jedes andere Muster existiert, um eine spezifische Lücke zu schließen, in der REST versagt: GraphQL kommt zum Einsatz, wenn die benötigten Daten je nach Client variieren, WebSockets, wenn eine Verbindung in beide Richtungen offen bleiben muss, Webhooks, wenn man auf Ereignisse reagieren statt ständig danach zu fragen, gRPC, wenn JSON für den internen Serviceverkehr zu langsam wird, und SOAP, wenn unternehmensweite Sicherheitsanforderungen keine andere Option zulassen.

Nächstes Mal, wenn Sie eine Integration entwerfen, beginnen Sie nicht damit, zu überlegen, wie man REST zwangsläufig einsetzen kann. Fragen Sie stattdessen, welches Kommunikationsmuster tatsächlich zu den Anforderungen des Systems passt. Diese Antwort sollte über das gewählte Tool entscheiden – nicht die Gewohnheit.

Als nächster Schritt wählen Sie eines dieser Muster, mit denen Sie noch nicht gearbeitet haben. Finden Sie die offizielle Dokumentation dazu oder ein kleines Open-Source-Projekt, das darauf basiert, und lesen Sie eine echte Implementierung durch, bevor Sie unter Druck gezwungen werden, selbst eines zu entwickeln.