Un aggiornamento di ordine può avere due consumatori: il tuo database e il cliente che osserva la pagina dell'ordine. Servono comportamenti di recupero diversi quando una connessione cade.
Il tuo database ha bisogno di un record recuperabile dell'evento. La pagina del cliente potrebbe aver bisogno solo dell'ultimo stato dell'ordine dopo la riconnessione.
Quali sono le quattro opzioni?
Bird offre webhook, Realtime, uno stream di eventi dashboard e letture API che puoi interrogare con il polling.
Usa i webhook per ricevere eventi sul tuo server. Usa Realtime per aggiornare i client connessi. Lo stream SSE invia le modifiche alle risorse a una sessione dashboard. Il polling consente alla tua applicazione di leggere lo stato delle risorse a intervalli regolari.
| Meccanismo | Direzione | Autenticazione | Recupero dopo disconnessione |
|---|---|---|---|
| Webhook | Bird invia al tuo server. | Il tuo ricevitore verifica una firma con il proprio endpoint secret. | Le consegne fallite vengono riprovate. Gli eventi mancati possono essere riprodotti. |
| Realtime | Il tuo server pubblica verso i client connessi. | I client si connettono con una app key. Le sottoscrizioni private richiedono l'autorizzazione del backend. | I client che si riconnettono hanno bisogno del recupero dello stato. |
| Stream SSE | Bird invia le modifiche alle risorse a una sessione dashboard. | Un cookie di sessione dashboard. | Leggi di nuovo la risorsa per ottenerne lo stato. |
| Polling | La tua applicazione chiede lo stato a Bird. | Una chiave API. | Una lettura successiva restituisce lo stato della risorsa, senza ricostruire ogni transizione. |
Quando i webhook sono la risposta giusta?
Usa i webhook quando il tuo server deve reagire agli eventi e recuperare le consegne mancate.
Registra un endpoint HTTPS raggiungibile pubblicamente. Sottoscrivilo ai tipi di evento che ti servono. Il tuo ricevitore verifica prima la firma. Poi salva l'evento. Conferma la ricezione prima che inizi l'elaborazione lenta.
Bird esegue fino a otto tentativi in circa 27,5 ore prima degli aggiustamenti di tempistica. Questa finestra dà al ricevitore il tempo di riprendersi da un'interruzione. Il replay degli eventi mancati offre un ulteriore percorso di recupero.
Deduplica in base a webhook-id perché lo stesso evento può arrivare più volte. Confronta i tempi di occorrenza degli eventi prima di sovrascrivere lo stato, perché gli eventi possono arrivare fuori ordine.
Tentativi webhook falliti copre i limiti di recupero. Gestione dei duplicati copre il salvataggio sicuro dell'evento prima di restituire un successo.
Quando usare Realtime?
Usa Realtime quando un browser o un'applicazione connessa ha bisogno di aggiornamenti man mano che il tuo server li pubblica.
Un canale è una destinazione con un nome a cui i client si sottoscrivono. Il tuo server pubblica un evento su quel nome e i client sottoscritti lo ricevono sulle loro connessioni. Questo può aggiornare una pagina ordine, una conversazione chat o un indicatore di avanzamento senza ricaricare la pagina.
Realtime non riproduce tutti gli eventi persi da un client disconnesso. Mantieni lo stato persistente nel tuo database e ripristina la vista dopo la riconnessione.
Un canale cache conserva l'ultimo evento per i nuovi sottoscrittori finché il valore in cache resta disponibile. Non mantiene una cronologia degli eventi. Se avvengono due aggiornamenti mentre un client è offline, il valore in cache più recente non può recuperare l'aggiornamento intermedio.
La app key è visibile nel codice client, quindi un canale pubblico può essere letto da un visitatore che possiede quella chiave. Un canale che inizia con private- richiede che il tuo backend autorizzi la sottoscrizione. Un canale presence- condivide anche le identità dei membri sottoscritti.
I nomi dei canali accettano da 1 a 164 caratteri tra lettere, cifre e _ - = @ , . ;. Il prefisso fa parte di quel limite, quindi includilo quando validi un nome generato.
Realtime invia anche webhook quando un canale acquisisce il primo sottoscrittore o perde l'ultimo. I webhook di appartenenza indicano quali membri si sono uniti o hanno lasciato il canale. Configurali dalla dashboard. Publish/subscribe e webhook a confronto spiega come i due meccanismi funzionano insieme.
Bird ha un endpoint SSE?
Bird ha un endpoint SSE, getEventsStream, per le sessioni dashboard autenticate.
GET /v1/events/stream segnala le modifiche alle risorse API. Una notifica identifica il tipo di risorsa, l'identificatore e il momento dell'occorrenza, così la dashboard può recuperare i dati della risorsa.
L'endpoint accetta un cookie di sessione dashboard. Non accetta una chiave API, quindi usa webhook o polling per un'integrazione basata su chiave API.
Quando è corretto usare il polling?
Usa il polling quando ti serve lo stato di una risorsa, non puoi ricevere richieste in arrivo o non esiste un evento pubblico per la modifica.
Usa il polling per verificare se un operatore ha approvato il tuo numero toll-free per l'invio di messaggi. Bird non ha un evento webhook pubblico per quella decisione di verifica. Leggi la verifica a intervalli regolari tramite bird sms tfn verifications get, o il corrispondente strumento agente. L'operazione command è fuori dal bundle pubblico API.
Il polling funziona anche per una rete che consente richieste in uscita ma non può esporre un ricevitore. Se ti serve solo lo stato attuale, leggere la risorsa evita di ricostruirla dagli eventi passati.
Letture e liste consumano budget di limitazione delle richieste per credenziale attiva all'interno di un'organizzazione. Attendi prima di riprovare dopo una risposta HTTP 429. Adatta l'intervallo alla velocità con cui la tua applicazione deve rilevare una modifica.
Webhook, Realtime e limiti di frequenza coprono la configurazione per questi percorsi.
Cosa scegliere?
Scegli in base a chi consuma l'aggiornamento e a cosa deve sopravvivere a una disconnessione.
- Webhook quando il tuo server deve elaborare eventi con tentativi ripetuti e recupero degli eventi mancati.
- Realtime quando le schermate connesse hanno bisogno di aggiornamenti e possono recuperare dallo stato salvato dopo la riconnessione.
- Polling quando ti serve lo stato della risorsa, non puoi esporre un ricevitore o non esiste un evento pubblico.
- Lo stream SSE per una sessione dashboard Bird autenticata.
In breve
Scegli i webhook per la gestione degli eventi lato server.
Usa i tentativi ripetuti e il replay degli eventi mancati quando il tuo server deve recuperare le consegne dopo un'interruzione.
Scegli Realtime per le schermate connesse.
Ripristina la vista dallo stato salvato quando il client si riconnette.
Scegli il polling per lo stato delle risorse.
Usa il polling quando non puoi esporre un ricevitore, non hai un evento pubblico o ti serve solo lo stato della risorsa.
Usa SSE per una sessione dashboard Bird.
Lo stream richiede l'autenticazione di una sessione dashboard.