web-dev-qa-db-fra.com

Est-ce Ok pour utiliser HTTP REST API pour l'application Chat)?

Nous construisons une application de chat sur Android. Nous envisageons d'utiliser HTTP REST pour envoyer des messages sortants. Nous voulions savoir si c'est une bonne approche ou si elle présente des inconvénients par rapport à l'utilisation de WebSockets ou XMPP (qui semble être davantage une norme de facto) pour transférer des messages de chat)?

Certains des avantages/inconvénients que je peux penser sont:
+ Le point de terminaison HTTP est facile à mettre à l'échelle horizontalement côté serveur (il s'agit d'une préoccupation principale)
+ La courbe d'apprentissage des Websockets est plus abrupte que HTTP
- Les messages HTTP auraient une charge utile plus importante que les sockets Web

Selon ce document, il semble que même Facebook ait utilisé AJAX pour gérer les messages de discussion initialement:

https://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf

androidxmppchat
21
Madhur Ahuja

Nous pouvons utiliser REST API pour la messagerie instantanée, mais à mon humble avis, XMPP est une meilleure alternative. Voyons ce que XMPP a à offrir.

XMPP en plus de prendre en charge TCP fournit également HTTP (via l'interrogation et la liaison ) et transports websocket . Lecture XMPP via HTTP et transports WebSocket

Il serait intéressant de comprendre les avantages et les inconvénients de chaque transport du point de vue XMPP.

XMPP pourrait utiliser HTTP de deux manières: polling [18] et liaison .

Interrogation XMPP sur HTTP

La méthode d'interrogation, désormais obsolète, implique essentiellement que les messages stockés sur une base de données côté serveur sont récupérés (et publiés) régulièrement par un client XMPP au moyen de requêtes HTTP 'GET' et 'POST'.

Liaison XMPP sur HTTP (BOSH)

La méthode de liaison est considérée comme plus efficace que les requêtes HTTP standard 'GET' et 'POST' dans la méthode Polling car elle réduit la latence et la consommation de bande passante par rapport aux autres HTTP techniques de sondage

Cependant, cela présente également un inconvénient car les sockets restent ouverts pendant une longue période de temps, en attendant la prochaine demande du client

La méthode de liaison, implémentée à l'aide de flux bidirectionnels sur HTTP synchrone ( [~ # ~] bosh [~ # ~] ), [19] permet aux serveurs de Envoyez des messages aux clients dès leur envoi. Ce modèle de notification Push est plus efficace que l'interrogation, où de nombreux sondages ne renvoient aucune nouvelle donnée.

Ce serait bien si nous comprenons comment la technique BOSH fonctionne.

La technique employée par BOSH, parfois appelée "interrogation longue HTTP", réduit la latence et la consommation de bande passante par rapport aux autres techniques d'interrogation HTTP. Lorsque le client envoie une demande, le gestionnaire de connexions n'envoie pas immédiatement de réponse; au lieu de cela, il garde la demande ouverte jusqu'à ce qu'il ait des données à envoyer au client (ou qu'une durée d'inactivité convenue se soit écoulée). Le client envoie ensuite immédiatement une nouvelle demande au gestionnaire de connexions, poursuivant la longue boucle d'interrogation.

Si le gestionnaire de connexions n'a pas de données à envoyer au client après un certain temps convenu [12], il envoie une réponse avec un vide. Cela sert un objectif similaire aux blancs persistants ou Ping XMPP (XEP-0199) [13]; il permet de garder une connexion socket active, ce qui empêche certains intermédiaires (pare-feu, proxys, etc.) de la supprimer silencieusement, et aide à détecter les ruptures dans un délai raisonnable.

Liaison XMPP sur WebSocket

XMPP prend en charge la liaison WebSocket qui est un transport plus efficace

Un transport peut-être plus efficace pour la messagerie en temps réel est WebSocket, une technologie Web fournissant des canaux de communication bidirectionnels en duplex intégral sur une seule connexion TCP. La liaison XMPP sur WebSocket est définie dans le L'IETF a proposé la norme RFC 7395.

En parlant de la courbe d'apprentissage, oui, vous pourriez être tenté d'utiliser l'API REST, mais il existe maintenant plusieurs ressources pour en savoir plus sur Android et XMPP , et - logiciels du serveur XMPP que vous pouvez utiliser pour exécuter votre propre service XMPP, soit sur Internet, soit sur un réseau local. Cela vaut la peine de consacrer cet effort avant de décider de votre architecture.

14
random

Je pense qu'une approche REST peut fonctionner pour le chat. Supposons:

Si je comprends bien, votre question porte sur le dernier point.

Une fois que le client a posté un message extérieur à http://chat.example.com/conversations/12 , il fermera la connexion http.

L'inconvénient est que la réception de messages entrants n'est tout simplement pas possible dans ce cas. Vous aurez besoin d'un canal différent (peut-être simplement messagerie cloud Google ).

Au contraire, WebSockets et XMPP maintiennent la connexion active, ce qui leur permet de recevoir des messages sans délai. Mais l'inconvénient des deux est en effet que cela représente un coût pour le serveur, en termes d'évolutivité; et un coût pour le client en termes d'utilisation de la batterie.

Sur le serveur:

  • les sockets sont une ressource relativement rare
  • il n'est pas possible de déplacer des clients pour l'équilibrage de charge s'ils ont une connexion ouverte (mais pouvez-vous vraiment déplacer des clients de toute façon? cela dépend de la responsabilité des niveaux)

Sur le client:

9
rds

Il n'est pas recommandé d'utiliser l'API HTTP Rest pour le chat ou des applications similaires en temps réel.

Un aperçu ..

Configuration requise pour le client de chat

  1. Récupération de la liste d'amis

  2. Vérifier les amis en ligne/hors ligne

  3. Obtenez des messages de chat en temps réel et envoyez des messages.
  4. Recevez des notifications de livraison/lecture, etc.

Le point 1 est en quelque sorte une tâche unique après avoir démarré le client de chat, il peut donc être effectué avec un simple appel de repos, donc pas de frais généraux compliqués.

Reste tous les points auront besoin d'une vérification persistante des données du serveur ou d'une autre partie dans le cas du client p2p également. Ce qui vous fera créer des appels de repos d'interrogation longs ou courts pour surveiller les nouvelles données ou d'autres mises à jour.

Problème avec le client HTTP Rest

Ce n'est pas une communication de type Keep Alive en raison de laquelle vous devrez établir plusieurs connexions http qui auront tellement de frais généraux qu'elles deviendront trop lentes. La reconnexion étant très coûteuse dans les appels HTTP.

** Sockets Web ou XMPP ** Ils sont en mode de communication duplex et sont très bons pour gérer les push de données incrémentielles et vous ne créez pas de nouvelles connexions http donc cela donne des performances vraiment fluides.

Une autre solution Dans le cas où vous êtes bloqué avec certains systèmes hérités au cas où vous êtes obligé d'utiliser le mode api de repos.

Essayez CometD c'est une approche hybride de websockets et d'interrogation ajax qui vous donnera des communications en temps quasi réel ainsi que de travailler sur des clients qui ne supportent pas les websockets en tombant retour sur les mécanismes de polling ajax. Il utilise également diverses optimisations pour éviter de se reconnecter encore et encore.

lien CometD

Vous pouvez également essayer Socket.io qui est également une technologie étonnante pour résoudre ce genre de cas d'utilisation

6
Vikrant Mahajan

Réponse courte Non.

Je ne voudrais pas démarrer un nouveau projet ou recommander de démarrer un nouveau projet (puisque vous avez mentionné recommencer) qui nécessite une communication bidirectionnelle en direct qui repose sur HTTP - en tant que protocole sans état. Vous pouvez être rassuré que la connexion soit maintenue mais il n'y a aucune garantie.

Votre + HTTP endpoint is easy to scale horizontally on server side pro est un pro dans le contexte lorsque HTTP est utilisé comme style de demande et de réponse et lorsqu'il est considéré comme sans état. Cela devient quelque peu théorique (bien que pas entièrement) lorsque vous devez intrinsèquement maintenir la connexion en vie.

HTTP offre un autre avantage suivant que vous n'avez pas mentionné ici.

  • HTTP est facile à gérer avec les proxys de pare-feu d'entreprise lorsque d'autres ports peuvent être bloqués.

C'est là que WebSockets ou XMPP sur HTTP auront un meilleur taux de réussite comme mentionné par d'autres.

2
bhantol

Ça dépend. Considérez-vous votre application comme un "chat en direct"? Avez-vous besoin d'un indicateur de présence ou d'un indicateur de frappe? Des fonctionnalités telles que celles-ci nécessitent une connexion continue. Mais il existe un autre ensemble d'applications de chat que vous qualifieriez de "messagerie intégrée". Ces applications stockent les conversations et les listes de conversations sur une sorte de backend; installez simplement l'application sur un autre appareil et connectez-vous, et vous verrez vos conversations sur ce type d'application. Ces applications n'ont pas d'indicateur de présence ou de sensation de vivacité.

Bien que je n'ai implémenté aucune application avec XMPP, cela ressemble à la persistance des messages, la plus grande persistance que vous trouverez avec XMPP (prête à l'emploi) est persistante jusqu'à la livraison, similaire à SMS. Vous pourriez peut-être créer un mécanisme de stockage/récupération pour XMPP en capturant les strophes au fur et à mesure de leur passage et en les stockant dans votre propre base de données. Mais si vous n'avez pas besoin de l'expérience complète de "chat", l'utilisation d'une base de données, d'un service HTTP et de notifications Push (pour notifier les threads mis à jour) semble être un chemin solide pour les applications avec fonctionnalité de messagerie - que j'ai l'intention de mettre en œuvre dans un iOS et Android application pour moi en ce moment.

Faites-moi savoir si vous avez trouvé de bons schémas open source/API pour cela.

1
androidguy