Un servizio di notifica ha bisogno sia di un modo per inviare messaggi sia di un percorso verso i telefoni dei destinatari. Scegliere un'interfaccia risponde solo alla prima parte del problema.
Cosa fa ciascuna parte?
Un API accetta richieste programmatiche. Un gateway collega la tua applicazione alle reti mobili.
La tua applicazione invia destinatario, mittente e messaggio attraverso l'interfaccia. Il gateway inoltra i messaggi verso i servizi di rete che li recapitano. Un provider può fornire entrambe le parti in un unico servizio.
Il riferimento al gateway SMPP descrive i gateway che collegano le applicazioni ai centri messaggi mobili. Descrive anche gateway che offrono diverse interfacce, tra cui HTTP e SMPP.
L'interfaccia non determina ogni capacità di consegna. Un formato di richiesta comodo non può rendere valido un mittente non supportato in una destinazione.
Quale interfaccia scegliere?
Scegli HTTP per una nuova applicazione, a meno che un'integrazione SMPP esistente o un requisito di connessione specifico giustifichi la gestione di SMPP.
Con HTTP, la tua applicazione effettua richieste ed elabora risposte. Ha comunque bisogno di gestire i tentativi di riprovare, la protezione contro invii duplicati e gli eventi di consegna.
SMPP usa una connessione che resta aperta. Il tuo client autentica una sessione e gestisce la perdita di connessione, gli acknowledgment e le operazioni in ingresso. SMPP spiega quel lavoro.
Un sistema SMPP esistente può rendere quell'interfaccia una scelta pratica. Verifica le operazioni supportate e i limiti del provider prima di dare per scontato che un'altra connessione SMPP si comporti allo stesso modo.
Quali capacità di consegna confrontare?
Confronta copertura delle destinazioni, mittenti consentiti, throughput e report di errore utili rispetto alle esigenze della tua applicazione.
- Destinazioni: conferma il supporto per ogni paese che servi, perché una rotta funzionante non ne garantisce un'altra.
- Mittenti: verifica disponibilità e registrazione prima di impegnarti sull'identità che i destinatari vedranno.
- Throughput: distingui i limiti delle richieste dalla velocità con cui il percorso di consegna può trasportare il traffico.
- Eventi: verifica come i messaggi in ingresso e gli errori di consegna raggiungono la tua applicazione.
Le pagine sulle destinazioni di Bird pubblicano i requisiti specifici per paese. Tipi di mittente spiega le scelte di identità.
Perché la consegna arriva separatamente dall'accettazione?
La rete può completare la consegna dopo che la tua richiesta di invio è stata elaborata.
Un centro messaggi può trattenere un testo mentre un telefono è irraggiungibile. Centri messaggi spiega quella fase di attesa.
Mantieni invio e consegna come risultati separati nella tua applicazione. Altrimenti una richiesta accettata può sembrare riuscita anche quando un successivo report di consegna registra un errore.
Come invio tramite HTTP API di Bird?
Invii un messaggio, salvi il suo identificativo e gestisci gli eventi di consegna che seguono.
Usa POST /v1/sms/messages con to, from, text e category per un invio a testo libero. Imposta category su uno tra marketing, transactional, authentication o service. La guida all'invio documenta i campi supportati.
Una risposta 202 conferma l'accettazione. Non conferma la consegna al telefono. Traccia il id restituito attraverso gli eventi SMS in modo che il risultato finale aggiorni la richiesta corretta.
Quale percorso è adatto alla mia applicazione?
Scegli l'interfaccia che la tua applicazione può gestire in modo affidabile, poi verifica le capacità di consegna separatamente.
- Usa HTTP per una nuova integrazione che non ha requisiti SMPP specifici.
- Usa SMPP quando un sistema esistente o un comportamento di connessione richiesto giustifica la gestione della sessione.
- Verifica destinazioni, mittenti ed eventi di consegna prima di impegnare il traffico su uno dei due percorsi.
In breve
API e gateway svolgono compiti diversi.
API accetta la tua richiesta, mentre il gateway fornisce il percorso verso la rete mobile.
HTTP evita di gestire una sessione SMPP.
SMPP richiede il ripristino della connessione e la gestione della sessione oltre al flusso di invio dei messaggi.
Accettazione e consegna restano separate.
Una richiesta di invio riuscita non garantisce che il destinatario abbia ricevuto il messaggio.
Confronta il percorso di consegna oltre all'interfaccia.
Verifica il supporto alle destinazioni, i requisiti del mittente, il throughput e la segnalazione degli errori prima di scegliere un'integrazione.