REST-API und Webhook: Wo liegt der Unterschied?
Beide verbinden Systeme, aber die Richtung ist umgekehrt — und daraus folgt fast alles andere: Aktualität, Aufwand und die Frage, was bei einer Störung passiert.
Das lernen Sie
REST: Ihr System fragt
Bei einer REST-Schnittstelle stellt Ihr System die Anfrage und bekommt eine Antwort. Die Adresse benennt dabei die Sache, die Methode die Absicht.
GET /api/v1/auftraege?seit=2026-10-16 HTTP/1.1 Host: beispiel.de Authorization: Bearer <Zugangsschluessel> Accept: application/json # Antwort HTTP/1.1 200 OK Content-Type: application/json {"auftraege": [{"nummer": 10244, "status": "offen"}]}Der praktische Vorteil: Ihr System bestimmt den Zeitpunkt. War es eine Stunde nicht erreichbar, fragt es danach einfach wieder. Voraussetzung ist, dass die Schnittstelle den verpassten Zeitraum noch liefert, etwa über einen Zeitfilter mit ausreichender Aufbewahrung; Änderungen, die nur den aktuellen Stand betreffen, sind dann nicht rekonstruierbar.
Webhook: das andere System ruft an
Bei einem Webhook hinterlegen Sie beim anderen System eine Adresse. Passiert dort etwas, schickt es eine Anfrage an diese Adresse — ohne dass Sie gefragt haben.
Der Vorteil ist die Aktualität: Der Vorgang ist in Sekunden bei Ihnen statt beim nächsten Abruf. Der Preis sind drei Dinge, die es bei der Abfrage nicht gibt: Ihre Adresse muss von außen erreichbar sein, Sie müssen prüfen können, dass die Meldung echt ist, und Sie brauchen einen Plan für verlorene Meldungen.
Der letzte Punkt wird am häufigsten übersehen. War Ihr System für zwanzig Minuten nicht erreichbar, hängt es vom anderen System ab, ob es die Meldung wiederholt — und ob es das oft genug tut.
Ein Beispiel aus der Praxis
Warum man beides zusammen baut
Die übliche Lösung ist nicht entweder-oder, sondern beides: Webhooks für den Normalfall, dazu eine regelmäßige Abfrage als Netz darunter, die nachträgt, was nicht angekommen ist. Das wirkt doppelt und ist die Antwort auf die Frage, was bei einer Störung passiert.
Damit das funktioniert, muss die Verarbeitung wiederholbar sein: Dieselbe Meldung zweimal verarbeitet darf keinen zweiten Vorgang erzeugen. Dafür trägt jede Meldung eine eindeutige Kennung, die das empfangende System sich merkt.
Welches Muster passt?
Häufige Missverständnisse
Weiterführende Quellen
- RFC 9110 — HTTP Semantics Methoden, Statuscodes, Semantik
- RFC 9457 — Problem Details for HTTP APIs einheitliches Format für Fehlerantworten
Über den Autor
Fabian Lücker ist geschäftsführender Gesellschafter der PHP-Schmiede KG in Rheine und seit 2007 in der Softwareentwicklung tätig. Er verantwortet Entwicklung und Konzeption und schreibt hier über Entscheidungen, die in echten Projekten anfallen.