ir haben Anfang des Jahres einen kurzen Überblick über SMPP vs. REST veröffentlicht. Da die Frage immer wieder komplexer wird, als es der Artikel abdecken konnte, präsentieren wir Ihnen hier den ausführlicheren Entscheidungsleitfaden – den wir auch unseren neuen Unternehmenskunden bei der Integrationsplanung vorstellen.
Der grundlegende Unterschied liegt im Verbindungsmodell.
Eine HTTP-API arbeitet mit kurzlebigen Verbindungen, die auf Anfrage und Antwort basieren. Man sendet eine Nachricht per POST, erhält eine Antwort, und die Verbindung kann geschlossen werden. SMPP hingegen ist eine persistente, zustandsbehaftete TCP-Sitzung: Man bindet sich einmalig, hält den Socket offen und überträgt PDUs (submit_sm, deliver_sm) über Stunden oder Tage in beide Richtungen. Dieser architektonische Unterschied ist ausschlaggebend für nahezu alle nachfolgenden praktischen Abwägungen.
Durchsatz und Latenz
- HTTP: Jede Nachricht verursacht zusätzlichen TCP- und TLS-Handshake-Overhead, sofern keine aggressive Verbindungsbündelung eingesetzt wird. BroadNet setzt keine festen Ratenlimits pro Konto (siehe API-Ratenlimits), aber bei hohem Volumen wird der Overhead pro Anfrage zum Flaschenhals.
- SMPP: Kein Handshake pro Nachricht. Eine einzelne Bindung ermöglicht problemlos Hunderte bis Tausende von Transaktionen pro Sekunde (TPS); der Durchsatz wird durch die ausgehandelte Fenstergröße und den SMSC begrenzt, nicht durch den Verbindungsaufbau.
- Bei OTP-Datenverkehr entfällt durch SMPP der TLS-Handshake aus dem kritischen Pfad – was besonders dann von Bedeutung ist, wenn ein Bestätigungscode in weniger als zwei Sekunden übermittelt werden muss.
Lieferbelege
Bei SMPP werden Zustellbestätigungen als deliver_sm PDUs auf demselben Bind empfangen, über den die Daten gesendet wurden – in Echtzeit, direkt im Datenstrom, ohne zusätzliche Infrastruktur. Bei einer HTTP-API werden Zustellbestätigungen als Webhook-Callbacks an einen von Ihnen gehosteten Endpunkt zurückgesendet. Dies erfordert einen öffentlich erreichbaren, hochverfügbaren HTTPS-Dienst und den Abgleich der Callbacks mit den gesendeten Daten. Beide Ansätze sind korrekt; sie erfordern lediglich unterschiedliche betriebliche Verpflichtungen.
Betriebskosten – die Teilteams unterschätzen
Eine HTTP-Integration ist etwas, das ein einzelner Backend-Entwickler an einem Nachmittag implementiert und dann weitgehend vergisst. Eine SMPP-Integration hingegen erfordert Infrastruktur: Sie müssen den gesamten Lebenszyklus von Bindung und Unbindung, Keepalives von enquire_link, automatische Wiederverbindung mit Backoff, Fensterverwaltung, Sequenznummernverfolgung und einen reibungslosen Failover bei mehreren Bindungen managen. Das bedeutet echte, kontinuierliche Entwicklungsverantwortung. Viele Teams, die technisch für SMPP geeignet wären, sind mit HTTP besser bedient, einfach weil sie keinen permanenten Telekommunikationsprotokoll-Stack betreiben möchten.
Eine einfache Faustregel
- Anwendungsspezifischer Datenverkehr unterhalb von mehreren hundert Nachrichten pro Sekunde, kleines Team – verwenden Sie die HTTP-API.
- Bei dauerhaft mehreren hundert Nachrichten pro Sekunde oder Bedarf an persistenten Binds, latenzkritischen OTPs, wenn Sie ein Aggregator sind oder über eine bestehende SMPP-Infrastruktur verfügen – verwenden Sie SMPP 3.4.
- Unterschiedliche Anforderungen – viele BroadNet-Kunden nutzen SMPP für Massen- und ereignisgesteuerten Datenverkehr, während sie HTTP für interne Tools mit geringem Datenaufkommen verwenden. Die gleichzeitige Nutzung beider Methoden ist nicht ausgeschlossen.
BroadNet stellt für SMPP 3.4 und HTTPS dieselbe Routing-, Sender-ID-Konformitäts- und Zustellbarkeits-Engine bereit. Das gewählte Protokoll ändert die Integrationsstruktur, nicht aber die Nachrichtenqualität oder die Routen.
Eine Sache, die kein ausschlaggebender Faktor ist
Die Kosten pro Nachricht sind in unserem Netzwerk protokollübergreifend identisch – die Wahl von SMPP führt nicht zu einem Rabatt, und die Wahl von HTTP verursacht keinen Aufpreis. Wählen Sie das Verbindungsmodell anhand Ihrer Latenzanforderungen und der gewünschten operativen Reichweite Ihres Teams. Nicht anhand eines nicht existierenden Preisunterschieds.
Den vollständigen Vergleich finden Sie unter SMPP vs. HTTP-(REST-)API für SMS.