Sollte ich Webhooks, Polling oder Streaming verwenden?

Ein Bestellungs-Update kann zwei Konsumenten haben: Ihre Datenbank und den Kunden, der eine Bestellseite beobachtet. Sie benötigen unterschiedliches Wiederherstellungsverhalten, wenn eine Verbindung abbricht.

Ihre Datenbank benötigt einen wiederherstellbaren Datensatz des Events. Die Seite des Kunden braucht nach der Wiederverbindung möglicherweise nur den aktuellen Bestellstatus.

Welche vier Optionen gibt es?

Bird bietet Webhooks, Realtime, einen Dashboard-Event-Stream und API-Lesezugriffe, die Sie per Polling abrufen können.

Verwenden Sie Webhooks, um Events auf Ihrem Server zu empfangen. Verwenden Sie Realtime, um verbundene Clients zu aktualisieren. Der SSE-Stream sendet Ressourcenänderungen an eine Dashboard-Sitzung. Polling ermöglicht Ihrer Anwendung, den Ressourcenstatus nach einem Zeitplan abzufragen.

Wann sind Webhooks die richtige Antwort?

Verwenden Sie Webhooks, wenn Ihr Server auf Events reagieren und verpasste Zustellungen wiederherstellen muss.

Sie registrieren einen öffentlich erreichbaren HTTPS-Endpoint. Abonnieren Sie ihn für die Event-Typen, die Sie benötigen. Ihr Empfänger verifiziert zuerst die Signatur. Dann speichert er das Event. Er bestätigt die Zustellung, bevor die langsame Verarbeitung beginnt.

Bird unternimmt bis zu acht Versuche über ungefähr 27,5 Stunden vor Timing-Anpassungen. Dieses Zeitfenster gibt einem Empfänger Zeit, sich von einem Ausfall zu erholen. Missed-Event-Replay bietet einen zusätzlichen Wiederherstellungspfad.

Deduplizieren Sie anhand von webhook-id, da dasselbe Event mehrfach eintreffen kann. Vergleichen Sie Event-Zeitstempel, bevor Sie den Status überschreiben, da Events in falscher Reihenfolge eintreffen können.

Fehlgeschlagene Webhook-Wiederholungen behandelt Wiederherstellungsgrenzen. Duplikatbehandlung behandelt das sichere Speichern des Events vor der Erfolgsbestätigung.

Wann sollte ich stattdessen Realtime verwenden?

Verwenden Sie Realtime, wenn ein verbundener Browser oder eine Anwendung Updates benötigt, sobald Ihr Server sie veröffentlicht.

Ein Channel ist ein benanntes Ziel, das Clients abonnieren. Ihr Server veröffentlicht ein Event unter diesem Namen, und abonnierte Clients empfangen es über ihre Verbindungen. Das kann eine Bestellseite, eine Chat-Konversation oder eine Fortschrittsanzeige ohne Neuladen aktualisieren.

Realtime spielt nicht jedes Event ab, das ein getrennter Client verpasst hat. Halten Sie den dauerhaften Status in Ihrer Datenbank und stellen Sie die Ansicht nach der Wiederverbindung wieder her.

Ein Cache-Channel behält sein letztes Event für neue Subscriber, solange der zwischengespeicherte Wert verfügbar ist. Er speichert keinen Event-Verlauf. Wenn zwei Updates passieren, während ein Client offline ist, kann ein zwischengespeicherter letzter Wert das dazwischenliegende Update nicht wiederherstellen.

Der App-Key erscheint im Client-Code, sodass ein öffentlicher Channel von jedem Besucher mit diesem Key gelesen werden kann. Ein Channel, der mit private- beginnt, erfordert, dass Ihr Backend die Subscription autorisiert. Ein presence--Channel teilt zusätzlich die Identitäten der abonnierten Mitglieder.

Channel-Namen akzeptieren 1 bis 164 Zeichen aus Buchstaben, Ziffern und _ - = @ , . ;. Das Präfix zählt zu diesem Limit, daher sollten Sie es bei der Validierung eines generierten Namens berücksichtigen.

Realtime sendet auch Webhooks, wenn ein Channel seinen ersten Subscriber gewinnt oder seinen letzten verliert. Mitgliedschafts-Webhooks melden, welche Mitglieder beigetreten oder gegangen sind. Konfigurieren Sie diese über das Dashboard. Publish/Subscribe versus Webhooks erklärt, wie die beiden Mechanismen zusammenwirken.

Hat Bird einen SSE-Endpoint?

Bird hat einen SSE-Endpoint, getEventsStream, für authentifizierte Dashboard-Sitzungen.

GET /v1/events/stream meldet Änderungen an API-Ressourcen. Eine Benachrichtigung identifiziert den Ressourcentyp, den Bezeichner und den Zeitpunkt des Auftretens, damit das Dashboard die Daten der Ressource abrufen kann.

Der Endpoint akzeptiert ein Dashboard-Sitzungscookie. Er akzeptiert keinen API-Key, verwenden Sie daher Webhooks oder Polling für eine API-Key-Integration.

Wann ist Polling die richtige Wahl?

Verwenden Sie Polling, wenn Sie den Ressourcenstatus benötigen, keine eingehenden Anfragen empfangen können oder kein öffentliches Event für die Änderung existiert.

Fragen Sie per Polling ab, ob ein Carrier Ihre gebührenfreie Nummer für den SMS-Versand genehmigt hat. Bird hat kein öffentliches Webhook-Event für diese Verifizierungsentscheidung. Lesen Sie die Verifizierung nach einem Zeitplan über bird sms tfn verifications get oder das entsprechende Agent-Tool aus. Die Befehlsoperation liegt außerhalb des öffentlichen API-Bundles.

Polling funktioniert auch für ein Netzwerk, das ausgehende Anfragen erlaubt, aber keinen Empfänger exponieren kann. Wenn Sie nur den aktuellen Status benötigen, vermeidet das Lesen der Ressource den Neuaufbau aus vergangenen Events.

Lese- und Listenabfragen verbrauchen Budgets für die Begrenzung der Anfragerate pro handelnder Berechtigung innerhalb einer Organisation. Warten Sie vor einer erneuten Anfrage nach einer HTTP-429-Antwort. Passen Sie das Intervall daran an, wie schnell Ihre Anwendung eine Änderung erkennen muss.

Webhooks, Realtime und Begrenzung der Anfragerate behandeln die Konfiguration für diese Pfade.

Was sollte ich wählen?

Wählen Sie danach, wer das Update konsumiert und was einen Verbindungsabbruch überstehen muss.

1. Webhooks, wenn Ihr Server Events mit Wiederholungsversuchen und Missed-Event-Wiederherstellung verarbeiten muss.
2. Realtime, wenn verbundene Bildschirme Updates benötigen und sich nach der Wiederverbindung aus gespeichertem Status wiederherstellen können.
3. Polling, wenn Sie den Ressourcenstatus benötigen, keinen Empfänger exponieren können oder kein öffentliches Event existiert.
4. Der SSE-Stream für eine authentifizierte Bird-Dashboard-Sitzung.