REST, GraphQL oder Webhooks: Welche Schnittstelle passt?
REST passt für die meisten Schnittstellen zwischen Unternehmenssystemen, weil es sich gut betreiben, zwischenspeichern und dokumentieren lässt. GraphQL passt, wenn viele unterschiedliche Oberflächen sehr verschiedene Ausschnitte derselben Daten brauchen. Webhooks ergänzen beide: Sie melden Ereignisse, statt auf Abfragen zu warten.
Wenn zwei Systeme Daten austauschen sollen, steht früh die Frage nach der Art der Schnittstelle. Die Antwort beeinflusst, wie schnell andere Teams anbinden können, wie gut sich die Last steuern lässt und wie viel Sicherheitsarbeit nötig ist. Die drei Begriffe stehen dabei nicht auf derselben Ebene: REST und GraphQL beschreiben, wie ein System Daten abfragt, Webhooks beschreiben, wie ein System ein anderes über Ereignisse informiert.
Kurz
REST oder GraphQL: was für Ihr Projekt passt
Für Schnittstellen zwischen Geschäftssystemen, etwa zwischen einem Shopware-Shop und einer Warenwirtschaft wie JTL-Wawi, Xentral oder weclapp oder zwischen Portal und CRM, ist REST in den meisten Fällen die richtige Wahl. GraphQL spielt seine Stärken aus, wenn mehrere eigene Oberflächen, zum Beispiel eine Web-App und zwei mobile Apps, sehr unterschiedliche Daten aus demselben Bestand brauchen und das Team den Mehraufwand im Betrieb tragen kann. Webhooks setzen Sie zusätzlich ein, sobald ein System wissen muss, dass im anderen etwas passiert ist: Eine Zahlung ist eingegangen, ein Auftrag wurde storniert.
REST
REST: der robuste Standard
Eine REST-Schnittstelle bildet Daten als Ressourcen mit eigenen Adressen ab, etwa /orders/4711, und nutzt die Methoden von HTTP: GET zum Lesen, POST zum Anlegen, PUT oder PATCH zum Ändern, DELETE zum Löschen. Die Bedeutung von Methoden und Statuscodes ist im HTTP-Standard festgelegt. Wer eine REST-Schnittstelle zum ersten Mal sieht, versteht deshalb vieles ohne Handbuch.
Daraus folgen die Stärken im Alltag:
Caching: GET-Antworten lassen sich mit den üblichen HTTP-Mechanismen zwischenspeichern, im Browser, auf einem Proxy oder in einem CDN.
Werkzeuge: Jede Programmiersprache, jedes Automatisierungswerkzeug und jedes Testprogramm spricht HTTP und JSON.
Dokumentation: Mit OpenAPI entsteht eine maschinenlesbare Beschreibung, aus der sich Dokumentation, Testfälle und Client-Code erzeugen lassen.
Rechte und Grenzen: Jede Ressource hat eine eigene Adresse. Berechtigungen und Abfragegrenzen lassen sich deshalb pro Endpunkt festlegen.
Die Schwäche von REST zeigt sich bei Oberflächen, die viele verschiedene Daten auf einmal brauchen. Eine Detailseite lädt den Auftrag, dann den Kunden, dann die Positionen, also drei oder mehr Abfragen. Oder ein Endpunkt liefert 40 Felder, von denen die App nur fünf anzeigt. Beides lässt sich mit zusammengefassten Endpunkten oder wählbaren Feldern abmildern. Laravel bringt seit Version 13 Ressourcen nach der JSON:API-Spezifikation mit, die genau solche Feldauswahl und das Mitladen verknüpfter Daten standardisiert.
Ein Beispiel aus unserer Arbeit ist eine REST-API für ein internes Tools-Portal: Erst standen die Endpunkte, versioniert über ein Präfix in der URL und mit OpenAPI dokumentiert, dann entstanden die Oberflächen darauf.
GraphQL
GraphQL: flexible Abfragen mit Preis
Bei GraphQL gibt es einen einzigen Endpunkt. Der Client schickt eine Abfrage, in der er genau beschreibt, welche Felder und verknüpften Daten er haben will, und bekommt genau diese zurück. Grundlage ist eine eigene Spezifikation, deren aktuelle Ausgabe vom September 2025 stammt. Für Laravel gibt es mit Lighthouse ein verbreitetes Paket, das GraphQL-Schemata direkt mit Eloquent-Modellen verbindet.
Der Vorteil liegt bei den Oberflächen: Jede App holt in einer Abfrage, was sie für einen Bildschirm braucht, und das Backend muss nicht für jeden neuen Bildschirm einen neuen Endpunkt bekommen. Das Schema beschreibt alle Typen und Felder und dient als Vertrag zwischen Frontend und Backend.
Dafür fallen Kosten an, die in Schätzungen oft fehlen:
Caching: Abfragen laufen meist per POST an denselben Endpunkt. Die üblichen HTTP-Caches greifen nicht, Caching muss in der Anwendung gelöst werden.
Last: Ein Client kann tief verschachtelte Abfragen stellen, die das Backend stark belasten. Die Sicherheitsempfehlungen von OWASP raten deshalb, Abfragetiefe und Abfragekosten zu begrenzen und Zeitlimits zu setzen.
Datenbankzugriffe: Jedes Feld wird von einer eigenen Funktion aufgelöst. Ohne Bündelung entstehen schnell Hunderte einzelne Datenbankabfragen pro Anfrage.
Offenheit: Über die eingebaute Selbstauskunft, die Introspektion, kann jeder das ganze Schema auslesen. OWASP empfiehlt, sie in öffentlich erreichbaren Umgebungen abzuschalten.
Fehler: Fehler stecken oft in einer Antwort mit Status 200. Überwachung, die nur auf HTTP-Statuscodes schaut, sieht sie nicht.
Ob eine Oberfläche überhaupt so viel Flexibilität braucht, ist eine eigene Frage. Viele Anwendungen kommen mit serverseitig gerenderten Seiten aus, die gar keine öffentliche Schnittstelle für das eigene Frontend brauchen. Dazu mehr im Beitrag Single Page App ist nicht immer die Lösung.
Webhooks
Webhooks: Ereignisse statt Abfragen
Ein Webhook ist ein HTTP-Aufruf, den ein System an eine vereinbarte Adresse im anderen System schickt, sobald etwas passiert. Statt alle fünf Minuten nachzufragen, ob eine Zahlung eingegangen ist, bekommt der Shop eine Nachricht, wenn es so weit ist. Zahlungsanbieter, Versanddienstleister und Code-Plattformen arbeiten so.
Der Empfang sieht nach wenig Arbeit aus, hat aber drei Eigenheiten, die in jeder Umsetzung berücksichtigt werden müssen:
Schnell antworten, später verarbeiten. GitHub erwartet zum Beispiel innerhalb von 10 Sekunden eine Antwort mit Status 2xx, sonst gilt die Zustellung als gescheitert. Die Anwendung speichert die Nachricht deshalb zuerst, bestätigt den Empfang und verarbeitet sie danach in einer Warteschlange.
Doppelte Nachrichten erwarten. Viele Anbieter, etwa Zahlungsdienste, wiederholen eine Zustellung automatisch, wenn keine Bestätigung kam, auch wenn die erste Nachricht schon angekommen war. GitHub wiederholt fehlgeschlagene Zustellungen nicht automatisch. Dort stößt man eine erneute Zustellung von Hand oder per API an, für Zustellungen der letzten drei Tage. Doppelt kann eine Nachricht also auf beiden Wegen ankommen. Die Verarbeitung muss deshalb idempotent sein: Eine Zahlung, die schon verbucht ist, wird beim zweiten Mal übersprungen. Das gelingt, indem die ID jedes Ereignisses gespeichert und vor der Verarbeitung geprüft wird.
Reihenfolge nicht voraussetzen. „Storniert“ kann vor „angelegt“ eintreffen. Die Verarbeitung vergleicht deshalb Zeitstempel oder fragt den aktuellen Stand beim Absender per API nach.
Weil Webhooks ausfallen können und nicht jeder Anbieter von sich aus nachliefert, gehört ein regelmäßiger Abgleich dazu: Einmal pro Nacht fragt die Anwendung per API die Ereignisse des Tages ab und ergänzt, was gefehlt hat.
Übersicht
Entscheidungstabelle für Ihr Projekt
Die Tabelle ordnet typische Situationen einer Schnittstellenart zu. REST und GraphQL schließen sich nicht aus: Manche Anwendungen bieten Partnern eine REST-Schnittstelle an und nutzen intern GraphQL für die eigenen Apps. Wichtig ist, dass für jede Schnittstelle feststeht, wer sie nutzt, wer sie pflegt und wie Änderungen angekündigt werden. Wie wir das mit Auftraggebern klären, zeigt die Seite zu Schnittstellen und APIs.
| Passt meist | Warum | |
|---|---|---|
| Zwei Geschäftssysteme tauschen Daten (Shop und Warenwirtschaft, Portal und CRM) | REST | Gut zu betreiben, zu cachen und mit jedem Werkzeug anzusprechen |
| Öffentliche Schnittstelle für Partner und Kunden | REST mit OpenAPI-Beschreibung | Niedrigste Einstiegshürde, Dokumentation und Testfälle lassen sich erzeugen |
| Mehrere eigene Oberflächen mit sehr unterschiedlichem Datenbedarf | GraphQL | Jede Oberfläche holt in einer Abfrage, was sie braucht, wenn das Team Caching, Begrenzungen und Überwachung selbst lösen kann |
| Ein System muss sofort auf Ereignisse im anderen reagieren | Webhooks plus nächtlicher Abgleich per REST | Ereignisse kommen ohne ständiges Nachfragen, der Abgleich fängt verlorene Nachrichten auf |
| Große Datenmengen einmal täglich | Export als Datei oder Abruf in Seiten | Eine einzelne große Antwort bricht ab oder belastet den Server, Seiten mit klaren Grenzen lassen sich wiederholen |
Für alle drei
Was jede Schnittstelle braucht
Unabhängig von der Art braucht jede Schnittstelle dieselben Grundlagen, und die Arbeit dafür ist bei REST, GraphQL und Webhooks ähnlich groß:
Kurz beantwortet
Häufige Fragen
-
Nicht grundsätzlich. GraphQL spart Datenvolumen und Abfragen, wenn eine Oberfläche viele verknüpfte Daten braucht. REST profitiert dafür von HTTP-Caching, das bei GraphQL meist entfällt. Welche Variante im Betrieb schneller ist, hängt von den Abfragen und der Umsetzung im Backend ab.
-
Das ist verbreitet. Beide können auf dieselbe Geschäftslogik und Datenbank zugreifen, zum Beispiel REST für Partner und Automatisierungen, GraphQL für die eigenen Apps. Der Aufwand für Rechte, Tests und Dokumentation fällt dann zweimal an.
-
Der Absender signiert jede Nachricht mit einem gemeinsamen Geheimnis, der Empfänger prüft die Signatur, bevor er die Nachricht verarbeitet. Ein Zeitstempel in der Signatur verhindert, dass alte Nachrichten wieder eingespielt werden. Dazu kommen HTTPS, eine schwer zu erratende Adresse und die Speicherung der Ereignis-IDs gegen doppelte Verarbeitung.
Schnittstelle planen lassen
Zwei Systeme sollen miteinander sprechen? Wir klären, wer was braucht, wählen die Schnittstellenart und liefern sie mit OpenAPI-Beschreibung und Tests.
Nachweise
Quellen und Stand
Stand: 28.05.2026. HTTP-Standard, GraphQL-Spezifikation, OWASP-Empfehlungen und die Webhook-Dokumentation von GitHub.
Später erschienen: Wie doppelte Webhooks bei Zahlungsanbietern unter Last zum Problem werden, zeigt der Beitrag Black Friday: So bereiten Sie Ihren Onlineshop vor.
Artikel teilen