Est-il acceptable d'utiliser l'API HTTP REST pour l'application Chat?

Nous construisons une application de chat dans Android. Nous pensons utiliser l'API HTTP REST pour envoyer des messages sortants. Je voulais savoir si c'est une bonne approche ou a des inconvénients par rapport à l'utilisation de WebSockets ou XMPP (qui semble être plus une norme de facto pour le transfert de messages de discussion)?

Certains des avantages / inconvénients que je peux penser sont:
+ Le point d'extrémité HTTP est facile à dimensionner horizontalement sur le côté serveur (Ceci est une préoccupation principale)
+ La courbe d'apprentissage pour Websockets est plus forte par rapport à HTTP
– Les messages HTTP auraient une charge utile plus grande par rapport aux connexions Web

  • OnInfoListener n'est jamais appelé
  • Android C2DM Registration_ID taille maximale
  • Est-il possible d'utiliser Mozilla Persona (BrowserID) avec des applications mobiles?
  • Chargement de toutes les images de la galerie dans l'application dans Android
  • Comment envoyer des paramètres de publication dynamiquement (ou en boucle) dans OKHTTP 3.x dans Android?
  • Android Camera Intent: comment obtenir une photo pleine grandeur?
  • Selon ce document, il semble même que Facebook ait utilisé AJAX pour traiter les messages de discussion initialement:

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

  • Terminer l'activité parentale et actuelle dans Android
  • Impossible de résoudre: com.google.android.gms: play-services-measurement: 9.6.1
  • Manipulation de la notification de la barre d'état avant qu'elle ne s'affiche
  • Comment arrêter un fil?
  • Fopen dans le code JNI C est échoué pour le dossier placé dans le dossier d'actifs dans l'application Android
  • Modification des méta-données de manifeste à partir du code
  • 5 Solutions collect form web for “Est-il acceptable d'utiliser l'API HTTP REST pour l'application Chat?”

    Nous pouvons utiliser l'API REST pour la messagerie de chat, mais IMHO, XMPP est une meilleure alternative. Considérons ce que XMPP a à offrir.

    XMPP à côté de supporter le transport TCP fournit également des services de HTTP (via le sondage et la reliure ) et de la liaison Web . Lire XMPP via HTTP et les 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 façons: polling [18] et binding .

    XMPP sur HTTP Polling

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


    Reliure XMPP sur HTTP (BOSH)

    La méthode de liaison est considérée plus efficace que les requêtes HTTP «GET» et «POST» régulières dans la méthode Polling car elle réduit la latence et la consommation de bande passante par rapport à d'autres techniques de sondage HTTP

    Cependant, cela pose également un inconvénient que les sockets restent ouverts pendant une longue période, 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 transmettre les messages aux clients dès leur envoi. Ce modèle de notification push est plus efficace que le sondage, où plusieurs des sondages ne renvoient pas de nouvelles données.

    Il serait bon de comprendre comment fonctionne la technique BOSH .

    La technique employée par BOSH, parfois appelée «interrogation à long terme HTTP», réduit la latence et la consommation de bande passante par rapport à d'autres techniques de sondage HTTP. Lorsque le client envoie une demande, le gestionnaire de connexion n'émet pas immédiatement une réponse; Au lieu de cela, elle tient la demande ouverte jusqu'à ce qu'elle dispose de données pour envoyer effectivement au client (ou une durée d'inactivité convenue s'est écoulée). Le client envoie immédiatement une nouvelle requête au gestionnaire de connexion, en continuant la longue boucle d'interrogation.

    Si le gestionnaire de connexion n'a pas de données à envoyer au client après un délai convenu [12], il envoie une réponse avec un vide. Cela a un but similaire à l'espace blanc ou à XMPP Ping (XEP-0199) [13]; Il contribue à maintenir une connexion socket activée qui empêche certains intermédiaires (pare-feux, proxies, etc.) de la déposer silencieusement et aide à détecter les pauses dans un délai raisonnable.


    XMPP sur la liaison WebSocket

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

    Un transport peut-être plus efficace pour le messagerie en temps réel est WebSocket, une technologie Web fournissant des canaux de communication bidirectionnels bidirectionnels sur une seule connexion TCP. XMPP sur la liaison WebSocket est défini dans la norme RFC 7395 proposée par IETF.

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

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

    Une vue d'ensemble …

    Exigences du client Chat

    1. Liste des amis chercher

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

    3. Obtenir des messages de chat en temps réel et envoyer des messages.
    4. Recevoir des notifications de livraison / lecture, etc.

    Le point 1 est une sorte de travail une fois que vous avez commencé le client de discussion, ce qui peut être fait avec un appel de repos simple, donc pas de frais généraux complexes.

    Tous les points nécessiteront une vérification persistante des données du serveur ou d'une autre partie dans le cas du client p2p. Ce qui vous amènera à créer des appels de repos de vote long ou court 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 vivant en raison de laquelle vous devrez créer plusieurs connexions http qui auront tellement de frais généraux qu'il deviendra trop lâche. Comme la reconnexion est très coûteuse dans les appels HTTP.

    ** Sockets Web ou XMPP ** Ils sont en mode duplex de communication et sont très bons à gérer les données incrémentielles et vous ne créez pas de nouvelles connexions http, ce qui donne de bonnes performances.

    Une autre solution Si vous êtes coincé avec certains systèmes existants dans le cas où vous êtes obligé d'utiliser le reste du mode api.

    Essayez CometD, c'est une approche hybride des websockets et des sondages Ajax qui vous permettront de communiquer en temps réel et de travailler sur des clients qui ne prennent pas en charge les websockets en reculant sur les mécanismes de vote ajax. De plus, il utilise diverses optimisations pour éviter de se reconnecter encore et encore.

    Lien CometD

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

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

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

    Une fois que le client a affiché un message externe à http://chat.example.com/conversations/123 , il va fermer 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 le messagerie Google Cloud ).

    Au contraire, WebSockets et XMPP maintiennent la connexion en vie, donc ils peuvent recevoir des messages sans délai. Mais l'inconvénient des deux est bien que cela représente un coût sur le serveur, en termes d'évolutivité; Et un coût pour le client en termes d'utilisation de la batterie.

    Sur le serveur:

    • Les prises sont une ressource relativement rare
    • Il n'est pas possible de déplacer les 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:

    • Le maintien d'une connexion réseau est extrêmement coûteux. Réseau de 1 s ≈ 5 minutes de sommeil.
    • Les librairies XMPP ne fonctionnent pas très bien sur Android . Et je n'ai aucune idée du support de WebSockets sur Android .

    Réponse courte n °

    Je ne commencerai pas un nouveau projet ou je recommanderais de commencer un nouveau projet (puisque vous avez mentionné recommencer) qui nécessite une communication bi-directionnelle en direct qui repose sur HTTP – comme protocole sans état d'imposition. Vous pouvez vous réconforter que la connexion soit maintenue en vie, 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 où HTTP est utilisé comme style de demande et de réponse et lorsqu'il est considéré comme sans état d'affectation. Il devient quelque peu discutable (même si pas entièrement) lorsque vous devez conserver la connexion en toute sécurité.

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

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

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

    Ça dépend. Considérez-vous que votre application est un "chat en direct"? Avez-vous besoin d'un indicateur de présence ou d'un indicateur de saisie? Des fonctionnalités telles que celles nécessitant une connexion continue. Mais il existe un autre ensemble d'applications de chat que vous décrivez en tant que «messagerie dans l'application» activée. Ces applications stockent des conversations et des listes de conversation 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 du message, la persistance maximale que vous trouverez avec XMPP (hors de la boîte) est persistante jusqu'à livraison, semblable au SMS. Peut-être que vous pourriez construire un mécanisme de stockage / récupération pour XMPP en capturant des strophes au fur et à mesure qu'elles passent et les stockent 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 avertir les threads mis à jour) semble être un chemin solide pour les applications avec des fonctionnalités de messagerie – que j'ai l'intention de mettre en œuvre dans un iOS & Une application Android de ma part maintenant.

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

    coAndroid est un fan Android de Google, tout sur les téléphones Android, Android Wear, Android Dev et Android Games Apps.