Request-Response-API-Stile: REST vs. gRPC vs. GraphQL vs. SOAP

Trotz jahrelanger „X ist tot"-Prognosen ist keiner der großen API-Stile tatsächlich verschwunden — SOAP läuft nach wie vor in regulierten Branchen, REST dominiert öffentliche APIs, GraphQL treibt moderne Frontends an, und gRPC übernimmt die interne Service-zu-Service-Kommunikation. Ich habe einen praxisnahen Vergleich aller vier Stile (plus JSON-RPC) geschrieben, der sich darauf konzentriert, wo jeder Stil tatsächlich passt — nicht darauf, welcher abstrakt „gewinnt". Das hier ist die Kurzfassung; der vollständige Artikel auf Medium enthält die komplette Aufschlüsselung, eine Entscheidungstabelle und konkrete Szenario-Empfehlungen.

Die Kurzfassung

Die Faustregel, bei der ich gelandet bin: REST standardmäßig, gRPC zwischen den eigenen Services, GraphQL wenn Clients die Datenform bestimmen sollen, und SOAP nur, wenn eine Gegenpartei oder eine Compliance-Vorgabe es erzwingt. REST bleibt der sichere Standard für öffentliche APIs und hat gerade eine wirklich nützliche Ergänzung bekommen — die neue HTTP-QUERY-Methode (RFC, Juni 2026), mit der man komplexe Filter in einem JSON-Body versenden kann, während die Cache- und Idempotenz-Garantien von GET erhalten bleiben — etwas, das POST nie sicher leisten konnte.

Warum KI-Agenten die Rechnung verändern

Zwei Faktoren zählen inzwischen genauso viel wie reine Performance: Sicherheit, weil der API-Stil die Angriffsfläche bestimmt, und wie gut KI-Agenten die API als Tool nutzen können. REST mit einer OpenAPI-Spezifikation erweist sich hier als klarer Gewinner — es lässt sich fast eins zu eins auf LLM-Tool-Calling-Definitionen abbilden, und Modelle, die auf riesigen OpenAPI-Korpora trainiert wurden, sind darin einfach flüssiger als in allem anderen. Bei gRPCs binärem Protobuf ist es umgekehrt: für ein Modell, das eine Schnittstelle verstehen soll, unlesbar — aber für das Streaming, das Model-Serving-Infrastruktur wie vLLM tatsächlich braucht, wirklich hervorragend geeignet. Die Flexibilität von GraphQL wiederum öffnet einen neuen Fehlermodus — durch Prompt Injection ausgelöste Query-Amplifikation, bei der ein Agent dazu gebracht wird, tief verschachtelte, teure Queries zu erzeugen, gegen die einfache Tiefenlimits allein nicht helfen.

Schnelle Einordnung

• Backend für eine öffentliche Mobile-App → GraphQL, für exakte Feldauswahl über eine instabile Verbindung.
• Interne Microservice-zu-Microservice-Kommunikation → gRPC, für binäre Payloads, mTLS und Streaming.
• Legacy-Integration im Banken- oder Behördenumfeld → SOAP, weil WS-Security und SAML meist eine regulatorische Vorgabe sind, keine Vorliebe.
• Öffentliche API für Drittanbieter → REST, wegen Verbreitung, Caching und der sanftesten Lernkurve.
• Interne Services als Tools für KI-Agenten bereitstellen → REST + OpenAPI, wegen der Token-Effizienz und Zuverlässigkeit, die Agenten brauchen.

Der vollständige Artikel geht auf jeden Stil im Detail ein — SOAPs WS-Security-Modell, REST' neue QUERY-Methode und ihr BOLA/IDOR-Risiko, GraphQLs Verteidigung gegen Tiefenangriffe, gRPCs mTLS-Standardeinstellungen und wo JSON-RPC still und leise weiter gewinnt (Ethereum-Nodes, das Language Server Protocol) — plus die vollständige Entscheidungstabelle. Weiterlesen: den vollständigen Artikel auf Medium lesen →