Choisissez le modèle de messagerie selon le dispositif, les commandes, la propriété des API et la maintenance.
MQTT convient à la télémétrie persistante, aux mises à jour d’état et aux commandes. HTTP convient aux API requête-réponse, à la configuration, aux services web et aux intégrations où un dispositif ou un serveur demande une ressource précise.
Le protocole doit correspondre au parcours du dispositif et à l’équipe qui exploitera le service.
| Critère de décision | MQTT | HTTP |
|---|---|---|
| Mode de communication | Publication et abonnement à des topics pour états, télémétrie, commandes et événements. | Requête-réponse pour API, configuration, téléchargements et intégration de services. |
| Usage du dispositif | Dispositifs connectés durablement, transmettant leur état ou recevant des commandes. | Dispositifs ou services réalisant des appels occasionnels, récupérant des ressources ou dialoguant avec le web. |
| Effet sur le cloud | Exige structure des topics, identité, sessions, permissions et traitement des messages. | Exige points d’accès, authentification, reprises, contrats de données et propriété des API. |
| Risque pour l’acheteur | Concerne conception des topics, exploitation du broker, droits de commande et suivi. | Concerne stabilité des API, authentification, reprises, limites d’appel et propriété des intégrations. |
Le protocole affecte l’identité des dispositifs, les permissions, les journaux, la maintenance et les intégrations.
MQTT convient souvent mieux à la télémétrie, aux états et aux commandes. HTTP convient souvent aux API requête-réponse, à la configuration, aux fichiers et aux intégrations. Le choix dépend du comportement du dispositif et de la propriété du cloud.
Oui. MQTT peut porter les messages du dispositif et HTTP les comptes, tableaux de bord, configurations, fichiers ou intégrations. Définissez les interfaces ensemble pour que le support comprenne l’exploitation complète.
Définissez identité, champs de données, commandes, veille, authentification, reprises, journaux, propriété et responsabilités de maintenance avant de figer le protocole.