¿Está bien usar la API HTTP REST para la aplicación de chat?

Estamos creando una aplicación de chat en Android. Estamos pensando en usar HTTP REST API para enviar mensajes salientes. ¿Quería saber si es un buen enfoque o tiene alguna desventaja en comparación con el uso de WebSockets o XMPP (que parece ser más de un estándar de facto para la transferencia de mensajes de chat)?

Algunos de los pros / contras que puedo pensar son:
+ HTTP extremo es fácil de escalar horizontalmente en el lado del servidor (Esto es una preocupación principal)
+ La curva de aprendizaje para Websockets es más pronunciada en comparación con HTTP
– Los mensajes HTTP tendrían una carga útil mayor en comparación con los websockets

Según este documento, parece incluso Facebook utiliza AJAX para manejar los mensajes de chat inicialmente:

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

Podemos usar la API REST para mensajes de chat, pero IMHO, XMPP es una alternativa mejor. Consideremos lo que XMPP tiene que ofrecer.

XMPP además de soportar transporte TCP también proporciona HTTP (a través de polling y enlace ) y transportes websocket . Leer XMPP a través de transportes HTTP y WebSocket

Sería interesante entender los pros y los contras de cada transporte desde la perspectiva XMPP.

XMPP podría utilizar HTTP de dos maneras: polling [18] y binding .

Sondeo XMPP sobre HTTP

El método de sondeo, ahora obsoleto, implica esencialmente que los mensajes almacenados en una base de datos del servidor se obtienen (y se publican) regularmente por un cliente XMPP mediante solicitudes HTTP 'GET' y 'POST'.


XMPP sobre enlace HTTP (BOSH)

El método de enlace se considera más eficiente que las solicitudes HTTP 'GET' y 'POST' habituales en el método de sondeo porque reduce el consumo de latencia y ancho de banda sobre otras técnicas de sondeo HTTP

Sin embargo, esto también plantea una desventaja que los sockets permanezcan abiertos durante un largo periodo de tiempo, esperando la siguiente petición del cliente

El método de enlace, implementado mediante bidireccional-arroyos Over Síncrona HTTP ( BOSH ), [19] permite a los servidores enviar mensajes a los clientes tan pronto como se envían. Este modelo push de notificación es más eficiente que el sondeo, donde muchas encuestas no devuelven datos nuevos.

Sería bueno si entendemos cómo funciona la técnica BOSH .

La técnica empleada por BOSH, que a veces se denomina "sondeo HTTP largo", reduce el consumo de latencia y ancho de banda sobre otras técnicas de sondeo HTTP. Cuando el cliente envía una solicitud, el gestor de conexión no envía inmediatamente una respuesta; En su lugar mantiene la solicitud abierta hasta que tenga datos para enviar realmente al cliente (o una longitud de inactividad acordada ha transcurrido). El cliente envía inmediatamente una nueva solicitud al administrador de conexión, continuando el ciclo de sondeo largo.

Si el gestor de conexión no tiene datos para enviar al cliente después de un tiempo acordado [12], envía una respuesta con un vacío. Esto sirve un propósito similar a los espacios en blanco keep-alives o XMPP Ping (XEP-0199) [13]; Ayuda a mantener activa una conexión de socket, lo que impide que algunos intermediarios (firewalls, proxies, etc.) lo dejen caer silenciosamente y ayuda a detectar interrupciones en un tiempo razonable.


XMPP sobre enlace WebSocket

XMPP admite el enlace WebSocket, que es un medio de transporte más eficiente

Un transporte quizás más eficiente para la mensajería en tiempo real es WebSocket, una tecnología web que proporciona canales bidireccionales de comunicaciones full-duplex a través de una sola conexión TCP. XMPP sobre enlace WebSocket se define en el IETF propuesto RFC estándar 7395.

Hablando de la curva de aprendizaje, sí, es posible que se sienta tentado a usar la API REST, pero ahora hay varios recursos para aprender sobre Android y XMPP , y los softwares de servidor XMPP que puede usar para ejecutar su propio servicio XMPP, ya sea a través de Internet O en una red de área local. Valdría la pena gastar este esfuerzo antes de decidir su arquitectura.

No se sugiere usar la API de descanso HTTP para chat o aplicaciones similares en tiempo real.

Algunas reseñas ..

Requisitos del cliente de Chat

  1. Búsqueda de lista de amigos

  2. Compruebe amigos en línea / fuera de línea

  3. Obtener mensajes de chat en tiempo real y enviar mensajes.
  4. Recibir notificaciones de entrega / lectura, etc.

Punto 1 es una especie de trabajo de un tiempo después de iniciar el cliente de chat, por lo que se puede hacer con la llamada de descanso simple, por lo que no hay gastos generales complicados.

Descansar todos los puntos necesitará la comprobación persistente de datos del servidor u otra parte en el caso del cliente p2p también. Lo que le llevará a crear llamadas de descanso de sondeo largas o cortas para ver nuevos datos u otras actualizaciones.

Problema con el cliente HTTP Rest

No es un tipo de comunicación mantener vivo debido a que tendrá que hacer varias conexiones http que tendrán tanto sobrecarga que se volverá demasiado laggy. Como reconectar es muy costoso en las llamadas HTTP.

** Sockets Web o XMPP ** Son modo dúplex de comunicación y son muy buenos en el manejo de empujes de datos incrementales y no están creando nuevas conexiones http de nuevo por lo que ofrece un rendimiento real suave.

Otra solución En caso de que se queden con algunos sistemas heredados en el caso de que usted está obligado a utilizar el resto modo api.

Pruebe CometD es un enfoque híbrido de websockets y ajax polling que le dará cerca de comunicaciones en tiempo real, así como trabajar en clientes que no es compatible con websockets por caer de nuevo en los mecanismos de sondeo ajax. También utiliza varias optimizaciones para evitar volver a conectar una y otra vez.

Enlace CometD

También puede probar Socket.io que también es una tecnología increíble para resolver este tipo de casos de uso

Creo que un enfoque REST puede funcionar para el chat. Asumamos:

Si entiendo bien, su pregunta es sobre el último punto.

Una vez que el cliente ha enviado un mensaje de salida a http://chat.example.com/conversations/123 , cerrará la conexión http.

El inconveniente es que la recepción de mensajes entrantes simplemente no es posible en ese caso. Necesitarás un canal diferente (tal vez simplemente la mensajería en la nube de Google ).

Por el contrario, WebSockets y XMPP mantienen viva la conexión, por lo que pueden recibir mensajes sin demora. Pero el inconveniente de ambos es, de hecho, que esto representa un coste en el servidor, en términos de escalabilidad; Y un coste en el cliente en términos de uso de la batería.

En el servidor:

  • Son un recurso relativamente escaso
  • No es posible mover a los clientes para el equilibrio de carga si tienen una conexión abierta (pero puede realmente mover los clientes de todos modos? Esto depende de la responsabilidad de los niveles)

En el cliente:

  • Mantener una conexión de red es extremadamente caro. 1 s red ≈ 5 minutos de sueño.
  • Las librerías XMPP no funcionan necesariamente muy bien en Android . Y no tengo idea del soporte de WebSockets en android .

Respuesta corta No.

No iniciaría un nuevo proyecto ni recomendaría iniciar un nuevo proyecto (ya que mencionó comenzar de nuevo) que necesita una comunicación bidireccional en vivo que se basa en HTTP, como protocolo sin estado. Usted puede tener consuelo de que la conexión se mantiene viva, pero no hay garantía.

Su + HTTP endpoint is easy to scale horizontally on server side pro es un pro en el contexto cuando HTTP se utiliza como estilo de solicitud y respuesta y cuando se considera apátrida. Se vuelve algo discutible (aunque no enteramente) cuando es inherentemente necesario mantener la conexión viva.

HTTP ofrece otra ventaja siguiente que usted no ha mencionado aquí.

  • HTTP es fácil de tratar con proxies de cortafuegos corporativos cuando se pueden bloquear otros puertos.

Aquí es donde WebSockets o XMPP sobre HTTP tendrán una mejor tasa de éxito como han mencionado otros.

Depende. ¿Consideras que tu aplicación es "chat en vivo"? ¿Necesita un indicador de presencia o un indicador de mecanografía? Las características tales como ésos requieren la conexión continua. Pero hay otro conjunto de aplicaciones de chat que describirías como "mensajería en la aplicación" activada. Estas aplicaciones almacenan conversaciones y listas de conversación en algún tipo de backend; Simplemente instale la aplicación en otro dispositivo e inicie sesión y verá sus conversaciones sobre este tipo de aplicación. Estas aplicaciones no tienen ningún indicador de presencia o sensación de vivacidad.

Aunque no he implementado ninguna aplicación con XMPP, parece que en lo que respecta a la persistencia del mensaje, la mayor persistencia que encontrará con XMPP (fuera de la caja) es persistente hasta que se entregue, similar a SMS. Tal vez usted podría construir un mecanismo de almacenamiento / recuperación para XMPP mediante la captura de estrofas a medida que pasan a través y almacenar en su propio DB. Pero si no necesitas la experiencia completa de "chat", el uso de una base de datos, el servicio HTTP y las notificaciones push (para notificar de los subprocesos actualizados) parece una ruta sólida para aplicaciones con funcionalidad de mensajería, Aplicación de Android de mi propio ahora.

Hazme saber si has encontrado algún buen esquema de código abierto / diseño de API para esto.

  • Cómo recuperar un historial de chat de Openfire usando asmack android
  • Smack mensaje oyente no llamado y conexión inestable
  • Inhibición de inicio de sesión La autenticación SASL falló al utilizar el mecanismo DIGEST-MD5 asmack en android
  • ¿Cómo obtener el estado del mensaje leído / no leído usando XMPP Smack API?
  • Asmack XMPP nuevo registro de usuario
  • Cómo crear una cuenta de Smack 4.1
  • Cómo saber Escribir Estado en XMPP openfire usando Smack
  • XMPP y Android
  • ¿Es posible enviar mensajes a través de GTalk Intent?
  • MQTT vs. XMPP ¿Qué debo elegir?
  • Chat de video de Android con XMPP
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.