Un service de notification a besoin à la fois d'un moyen de soumettre des textes et d'une route vers les téléphones des destinataires. Choisir une interface ne répond qu'à la première partie de ce problème.
Quel est le rôle de chaque partie ?
Une API accepte les requêtes programmatiques. Une passerelle relie votre application aux réseaux mobiles.
Votre application soumet un destinataire, un expéditeur et un message via l'interface. La passerelle transmet les messages vers les services réseau qui les livrent. Un fournisseur peut proposer les deux parties dans un seul service.
La référence de passerelle SMPP décrit les passerelles reliant les applications aux centres de messages mobiles. Elle décrit aussi les passerelles proposant plusieurs interfaces, dont HTTP et SMPP.
L'interface ne détermine pas toutes les capacités de livraison. Un format de requête pratique ne peut pas rendre un expéditeur non pris en charge valide dans une destination.
Quelle interface choisir ?
Choisissez HTTP pour une nouvelle application, sauf si une intégration SMPP existante ou une exigence de connexion spécifique justifie de gérer SMPP.
Avec HTTP, votre application effectue des requêtes et traite les réponses. Elle a toujours besoin de réessais, d'une protection contre les envois en double et de la gestion des événements de livraison.
SMPP utilise une connexion qui reste ouverte. Votre client authentifie une session et gère les pertes de connexion, les acquittements et les opérations entrantes. SMPP explique ce fonctionnement.
Un système SMPP existant peut rendre cette interface pertinente. Testez les opérations et limites prises en charge par le fournisseur avant de supposer qu'une autre connexion SMPP se comporte de manière identique.
Quelles capacités de livraison comparer ?
Comparez la couverture des destinations, les expéditeurs autorisés, le débit et les rapports d'échec utiles par rapport aux besoins de votre application.
- Destinations : confirmez la prise en charge de chaque pays que vous desservez, car une route fonctionnelle n'en garantit pas une autre.
- Expéditeurs : vérifiez la disponibilité et l'enregistrement avant de vous engager sur l'identité que les destinataires verront.
- Débit : distinguez les limites de requêtes du rythme auquel le chemin de livraison peut acheminer le trafic.
- Événements : vérifiez comment les messages entrants et les échecs de livraison parviennent à votre application.
Les pages de destination de Bird publient les exigences par pays. Types d'expéditeurs explique les choix d'identité.
Pourquoi la livraison arrive-t-elle séparément de l'acceptation ?
Le réseau peut terminer la livraison après la fin de votre requête de soumission.
Un centre de messages peut conserver un texte tant qu'un téléphone est injoignable. Centres de messages explique cette étape d'attente.
Conservez la soumission et la livraison comme des résultats distincts dans votre application. Sinon, une requête acceptée peut sembler réussie même lorsqu'un rapport de livraison ultérieur enregistre un échec.
Comment envoyer via l'HTTP API de Bird ?
Vous soumettez un message, enregistrez son identifiant et traitez les événements de livraison qui suivent.
Utilisez POST /v1/sms/messages avec to, from, text et category pour un envoi en texte libre. Définissez category sur marketing, transactional, authentication ou service. Le guide d'envoi documente les champs pris en charge.
Une réponse 202 confirme l'acceptation. Elle ne confirme pas la livraison au téléphone. Suivez le id retourné via les événements SMS pour que le résultat final mette à jour la bonne requête.
Quel chemin convient à mon application ?
Choisissez l'interface que votre application peut exploiter de manière fiable, puis vérifiez les capacités de livraison séparément.
- Utilisez HTTP pour une nouvelle intégration sans exigence SMPP spécifique.
- Utilisez SMPP lorsqu'un système existant ou un comportement de connexion requis justifie sa gestion de session.
- Testez les destinations, les expéditeurs et les événements de livraison avant d'engager du trafic sur l'un ou l'autre chemin.
En bref
L'API et la passerelle remplissent des rôles différents.
L'API accepte votre requête, tandis que la passerelle fournit le chemin vers le réseau mobile.
HTTP évite de gérer une session SMPP.
SMPP exige la reprise de connexion et la gestion de session en plus de votre flux de messages.
Acceptation et livraison restent séparées.
Une requête d'envoi réussie ne prouve pas que le destinataire a reçu le message.
Comparez le chemin de livraison en plus de l'interface.
Vérifiez le support des destinations, les exigences d'expéditeur, le débit et le signalement des échecs avant de choisir une intégration.