ll'inizio di quest'anno abbiamo pubblicato un breve articolo su SMPP e REST. La questione continua a ripresentarsi con sfumature più complesse di quelle che abbiamo analizzato in quell'articolo, quindi ecco la guida decisionale più completa, quella che effettivamente presentiamo ai nuovi clienti aziendali durante la fase di pianificazione dell'integrazione.
La differenza fondamentale è il modello di connessione
Un'API HTTP si basa su richieste/risposte tramite connessioni di breve durata. Si invia un messaggio tramite POST, si riceve una risposta e la connessione può essere chiusa. SMPP, invece, utilizza una sessione TCP persistente e con stato: ci si connette una sola volta, si mantiene il socket aperto e si trasmettono in streaming PDU (submit_sm, deliver_sm) in entrambe le direzioni per ore o giorni. Questa singola differenza architetturale è alla base di quasi tutti i compromessi pratici descritti di seguito.
Throughput e latenza
- HTTP: ogni messaggio comporta un overhead di handshake TCP + TLS, a meno che non si gestisca in modo aggressivo il pool di connessioni. BroadNet non imposta nessun limite di velocità fisso per account (vedi limiti di velocità dell'API), ma ad alti volumi l'overhead per richiesta diventa il collo di bottiglia.
- SMPP: nessun handshake per messaggio. Una singola connessione supporta comodamente da centinaia a migliaia di transazioni al secondo; la velocità di trasmissione è limitata dalla dimensione della finestra negoziata e dall'SMSC, non dalla configurazione della connessione.
- Per il traffico OTP, SMPP elimina l'handshake TLS dal percorso critico, il che è significativo quando si cerca di inviare un codice di verifica in meno di due secondi.
Ricevute di consegna
Con SMPP, le ricevute di consegna arrivano come PDU deliver_sm sullo stesso bind utilizzato per l'invio: in tempo reale, in banda, senza infrastrutture aggiuntive. Con un'API HTTP, le DLR vengono restituite come callback webhook a un endpoint gestito dall'utente, il che significa che è necessario eseguire un servizio HTTPS accessibile pubblicamente e ad alta disponibilità e riconciliare i callback con gli invii. Nessuno dei due approcci è sbagliato; si tratta semplicemente di impegni operativi diversi.
Costo operativo: la parte che i team sottovalutano
Un'integrazione HTTP è qualcosa che un singolo sviluppatore backend realizza in un pomeriggio e poi in gran parte dimentica. Un'integrazione SMPP è un'infrastruttura: è necessario gestire il ciclo di vita di bind/unbind, i keepalive enquire_link, la riconnessione automatica con backoff, la gestione delle finestre, il tracciamento del numero di sequenza e il failover controllato tra più bind. Questa è una vera e propria responsabilità ingegneristica continua. Molti team che sarebbero tecnicamente idonei per SMPP traggono maggiori vantaggi da HTTP semplicemente perché non vogliono gestire uno stack di protocolli di telecomunicazione persistente.
Una semplice regola empirica
- Traffico modellato in base all'applicazione inferiore a diverse centinaia di messaggi al secondo, team ridotto — utilizza l'API HTTP.
- Se sostieni diverse centinaia di messaggi al secondo o ti servono bind persistenti, se gestisci OTP critici per la latenza, sei un aggregatore o disponi di un'infrastruttura SMPP esistente, utilizza SMPP 3.4.
- Esigenze contrastanti: molti clienti BroadNet utilizzano SMPP per il traffico di massa e quello attivato da trigger, mantenendo HTTP per gli strumenti interni a basso volume. Non esiste alcuna regola che vieti l'utilizzo di entrambi i protocolli.
BroadNet espone lo stesso motore di routing, conformità all'ID mittente e deliverability sia su SMPP 3.4 che su HTTPS. Il protocollo scelto modifica la struttura dell'integrazione, non la qualità dei messaggi o i percorsi.
Una cosa che non è un fattore decisivo
Il costo per messaggio è identico per tutti i protocolli sulla nostra rete: scegliere SMPP non dà diritto a sconti, né scegliere HTTP comporta costi aggiuntivi. La scelta deve basarsi sul modello di connessione, sulle esigenze di latenza e sulla superficie operativa che il tuo team desidera gestire, non su una differenza di prezzo inesistente.
Per il confronto completo punto per punto, vedi SMPP o API HTTP (REST) per gli SMS.