REST-API vs. Webhook: Unterschied, Beispiele und Arch…

Wann ruft ein Client eine REST-API auf und wann erhält er automatisch ein Ereignis über einen Webhook? Mit HTTP-Beispielen, Sicherheitsregeln und Retry-Strategien.

1. Zuerst die Grundlagen

Eine REST-API stellt Ressourcen und Operationen über HTTP bereit. Ein Client entscheidet, wann er anfragt. Ein Webhook ist dagegen ein HTTP-Callback, den ein Ereignis auslöst. REST beschreibt einen Architekturstil; Webhook beschreibt einen Zustellmechanismus. Beide Konzepte schließen sich nicht aus.

2. Pull und Push verstehen

Beim Polling fragt der Client beispielsweise jede Minute GET /api/orders/42 ab. Bei einem Webhook schickt das Quellsystem nach einer Auftragsänderung automatisch ein POST an eine registrierte Callback-Adresse. Das kann Verzögerungen reduzieren, bringt aber Anforderungen an Sicherheit und Wiederholbarkeit mit sich.

3. REST-Beispiel

Ein Shop fragt über GET eine Liste von Bestellungen ab und bekommt JSON zurück. Diese Art der Kommunikation eignet sich, wenn ein Client Daten gezielt nach Bedarf benötigt.

GET /api/orders/10042 HTTP/1.1
Accept: application/json

4. Webhook-Beispiel

Nach einer Statusänderung sendet der Shop ein JSON-Ereignis an eine Azure Function. Das empfangende System bestätigt die Annahme schnell und verarbeitet umfangreiche Arbeit asynchron. Ein HTTP 200 oder 202 sollte nur nach entsprechend sicherer Annahme zurückgegeben werden.

POST /webhooks/orders HTTP/1.1
Content-Type: application/json
X-Event-Id: evt-10042

{
  "eventId": "evt-10042",
  "type": "order.updated",
  "orderId": "10042",
  "status": "Shipped"
}

5. Webhook-Sicherheit

Eine öffentliche Callback-URL muss authentifiziert werden. Je nach Anbieter geschieht das über HMAC-Signatur, geteilte Geheimnisse, OAuth oder andere vertraglich festgelegte Mechanismen. Prüfe die Signatur auf Basis der original empfangenen Bytes und kontrolliere Zeitstempel, soweit vom Provider unterstützt. Eine geheime URL allein reicht nicht.

6. Doppelte Events und Reihenfolge

Ein Webhook kann mehrfach geliefert werden oder verspätet ankommen. Speichere die Event-ID dauerhaft und verarbeite dasselbe Ereignis nur einmal. Prüfe Versions- oder Zeitstempel, falls Ereignisse in anderer Reihenfolge eintreffen. Verlasse dich nicht auf eine garantierte Zustellung genau einmal.

7. Warum eine Queue hilfreich ist

Der Webhook-Empfänger validiert, authentifiziert und schreibt das Ereignis dauerhaft in eine Queue. Danach bestätigt er die Annahme. Ein Hintergrundworker führt die Geschäftslogik aus und kann Fehler gezielt wiederholen. Dieser Aufbau schützt gegen zeitweilige Zielsystemausfälle.

8. REST und Webhooks in Business Central

Business Central kann per AL-HttpClient externe REST-APIs aufrufen. Für eingehende Ereignisse kann eine Azure Function oder ein anderer abgesicherter Dienst als Webhook-Empfänger dienen und die Daten anschließend über freigegebene BC-APIs übertragen. Prüfe vorhandene Standard-Webhooks und Ereignisfunktionen der jeweiligen BC-Version.

9. Fehlerfälle testen

Sende denselben Event zweimal, unterbrich den Empfänger nach der Queue-Speicherung und teste ungültige Signaturen. Prüfe 400 bei fehlerhafter Payload, die definierte Antwort bei Authentifizierungsfehlern und 429/5xx-Verhalten nach Providervertrag.

10. Entscheidungshilfe

Nutze eine REST-Abfrage, wenn der Client Daten aktiv benötigt. Webhooks passen, wenn ein Ereignis schnell gemeldet werden soll. Häufig kombiniert man beides: Webhook meldet eine Änderung, danach lädt der Empfänger den aktuellen Datensatz über die REST-API.

REST-API vs. Webhook: Unterschied, Beispiele und Architektur