¿API Websocket para reemplazar la API REST?


101

Tengo una aplicación cuya función principal funciona en tiempo real, a través de websockets o long polling.

Sin embargo, la mayor parte del sitio está escrito de forma RESTful, lo que es bueno para las aplicaciones y otros clientes en el futuro. Sin embargo, estoy pensando en hacer la transición a una API websocket para todas las funciones del sitio, lejos de REST. Eso me facilitaría la integración de funciones en tiempo real en todas las partes del sitio. ¿Esto dificultaría la creación de aplicaciones o clientes móviles?

Descubrí que algunas personas ya están haciendo cosas como esta: SocketStream


2
La encuesta larga de @Stegi funciona bastante bien como alternativa, no muy preocupada por eso.
Harry

2
Harry, ahora después de 7 años, ¿cómo te funcionó? Me pregunto, ya que también quiero moverme en esa dirección. @Harry
Dmitry Kudryavtsev

2
@DmitryKudryavtsev Terminé no haciéndolo. El método tradicional funcionó bien para mí y no fue mucho más difícil.
Harry

Respuestas:


97

Por no decir que las otras respuestas aquí no tienen mérito, tienen algunos puntos buenos. Pero voy a ir en contra del consenso general y estar de acuerdo contigo en que pasar a websockets para algo más que funciones en tiempo real es muy atractivo.

Estoy considerando seriamente mover mi aplicación de una arquitectura RESTful a un estilo más RPC a través de websockets. Esta no es una "aplicación de juguete", y no estoy hablando solo de funciones en tiempo real, así que tengo reservas. Pero veo muchos beneficios en seguir esta ruta y creo que podría convertirse en una solución excepcional.

Mi plan es usar DNode , SocketIO y Backbone . Con estas herramientas, mis modelos y colecciones de Backbone se pueden pasar desde / hacia el cliente y el servidor simplemente llamando a funciones al estilo RPC. No más gestión de puntos finales REST, serialización / deserialización de objetos, etc. Todavía no he trabajado con socketstream, pero parece que vale la pena echarle un vistazo.

Todavía me queda un largo camino por recorrer antes de poder decir definitivamente que esta es una buena solución, y estoy seguro de que no es la mejor solución para todas las aplicaciones, pero estoy convencido de que esta combinación sería excepcionalmente poderosa. Admito que existen algunos inconvenientes, como perder la capacidad de almacenar recursos en caché. Pero tengo la sensación de que las ventajas los superarán.

Me interesaría seguir su progreso explorando este tipo de solución. Si tiene algún experimento de github, por favor indíquemelo. Todavía no tengo ninguno, pero espero hacerlo pronto.

A continuación se muestra una lista de enlaces para leer más tarde que he estado recopilando. No puedo garantizar que todos valgan la pena, ya que solo he echado un vistazo a muchos de ellos. Pero espero que algunos ayuden.


Gran tutorial sobre el uso de Socket.IO con Express. Expone sesiones rápidas a socket.io y explica cómo tener diferentes salas para cada usuario autenticado.

Tutorial sobre node.js / socket.io / backbone.js / express / connect / jade / redis con autenticación, hosting Joyent, etc:

Tutorial sobre el uso de Pusher con Backbone.js (usando Rails):

Cree una aplicación con backbone.js en el cliente y node.js con express, socket.io, dnode en el servidor.

Usando Backbone con DNode:


1
Acabo de responder una pregunta relacionada e incluí algunos pensamientos más: stackoverflow.com/questions/4848642/…
Tauren

11
"Aún me queda un largo camino por recorrer antes de poder decir definitivamente que esta es una buena solución" - Solo curiosidad, ¿fue realmente una buena solución? : D
inf3rno

7
Responde @Tauren. Estoy muy interesado en lo que tienes que decir ahora.
No_name

4
@Tauren También tengo curiosidad por saber cómo funcionó esto.
Kurren

57

HTTP REST y WebSockets son muy diferentes. HTTP no tiene estado , por lo que el servidor web no necesita saber nada y usted obtiene almacenamiento en caché en el navegador web y en los proxies. Si usa WebSockets, su servidor se está volviendo con estado y necesita tener una conexión con el cliente en el servidor.

Comunicación de solicitud-respuesta vs Push

Use WebSockets solo si necesita PUSH datos del servidor al cliente, ese patrón de comunicación no está incluido en HTTP (solo por soluciones alternativas). PUSH es útil si los eventos creados por otros clientes deben estar disponibles para otros clientes conectados, por ejemplo, en juegos donde los usuarios deben actuar sobre el comportamiento de otros clientes. O si su sitio web está monitoreando algo, donde el servidor envía datos al cliente todo el tiempo, por ejemplo, mercados de valores (en vivo).

Si no necesita PUSH de datos del servidor, generalmente es más fácil usar un servidor HTTP REST sin estado. HTTP usa una simple solicitud-respuesta patrón de comunicación de .


5
Estamos muy acostumbrados al patrón de una dirección porque nunca antes habíamos tenido alternativas. Pero ahora, a medida que mi aplicación se vuelve más desarrollada, se me hace más evidente que cuantos más lugares en los que se usa la tecnología push, más receptiva y más atractiva se vuelve la aplicación.
Harry

Mi aplicación muestra una lista de amigos y la cantidad de puntos que tienen, por ejemplo. ¿Por qué no actualizarlo en tiempo real? Si los usuarios pueden ver el progreso de sus amigos, es posible que estén más inclinados a querer ponerse al día. Tengo ciertos modelos de documentos que, si bien no se cambian exactamente con frecuencia, se modifican lo suficiente como para que no actualizarlos en tiempo real pueda causar una ligera confusión. En algún momento, su sitio se beneficia lo suficiente de tener actualizaciones automáticas que comienza a mirar su código y la mitad se trata de REST y la otra mitad se trata de sockets y dice, bueno, quiero unificar esto.
Harry

3
Es una opción usar websockets solo para enviar una notificación / comando a su aplicación web (como getUpdate o refreshObjectWithId con params). Este comando podría analizarse en su aplicación web (cliente) y seguirse de una solicitud de descanso para obtener datos específicos en lugar de transportar los datos en sí a través de los websockets.
Beachwalker

2
Hay muchas razones por las que los websockets pueden ser más fáciles que las llamadas REST, no solo para empujar. websocket.org/quantum.html
BT

Los WebSockets son increíbles y liberan al servidor para enviar los datos del cliente en cualquier momento, no solo en respuesta a un mensaje del cliente. WebSockets implementa un protocolo basado en mensajes para que los clientes puedan recibir mensajes en cualquier momento y, si están esperando un mensaje en particular, pueden poner en cola otros mensajes para procesarlos más tarde, reordenar los mensajes en cola, ignorar los mensajes enviados según el estado de la aplicación, etc. Nunca volveré a escribir otra aplicación basada en REST. Flash también lo hace fácil, con implementaciones de WebSocket de código abierto basadas en AS3 y respaldo al navegador a través de los métodos ExternalInterface. (AddCallback / call).
Triynko

40

Estoy pensando en hacer la transición a una API de WebSocket para todas las funciones del sitio.

No. No deberías hacerlo. No hay ningún daño si admite ambos modelos. Utilice REST para comunicaciones unidireccionales / solicitudes simples y WebSocket para la comunicación bidireccional, especialmente cuando el servidor desea enviar una notificación en tiempo real.

WebSocket es un protocolo más eficiente que RESTful HTTP, pero sigue obteniendo puntuaciones RESTful HTTP sobre WebSocket en las áreas siguientes.

  1. Los recursos de creación / actualización / eliminación se han definido bien para HTTP. Tienes que implementar estas operaciones a bajo nivel para WebSockets.

  2. Las conexiones de WebSocket escalan verticalmente en un solo servidor mientras que las conexiones HTTP escalan horizontalmente. Existen algunas soluciones patentadas no basadas en estándares para el escalado horizontal de WebSocket.

  3. HTTP viene con muchas características buenas, como almacenamiento en caché, enrutamiento, multiplexación, gzipping, etc. Estas deben construirse sobre Websocket si elige Websocket.

  4. Las optimizaciones de motores de búsqueda funcionan bien para las URL HTTP.

  5. Todos los servidores de seguridad Proxy, DNS y cortafuegos aún no son plenamente conscientes del tráfico de WebSocket. Permiten el puerto 80, pero pueden restringir el tráfico fisgoneando primero.

  6. La seguridad con WebSocket es un enfoque de todo o nada.

Eche un vistazo a este artículo para obtener más detalles.


3
Esta es la mejor respuesta.
MattWeiler

1
Respuesta principal para el tema
Sanandrea

10

El único problema con el que puedo usar TCP (WebSockets) como su principal estrategia de entrega de contenido web es que hay muy poco material de lectura sobre cómo diseñar la arquitectura e infraestructura de su sitio web usando TCP.

De modo que no se puede aprender de los errores de otras personas y el desarrollo será más lento. Tampoco es una estrategia "probada y comprobada".

Por supuesto, también perderá todas las ventajas de HTTP (ser sin estado y el almacenamiento en caché son las mayores ventajas).

Recuerde que HTTP es una abstracción de TCP diseñada para servir contenido web.

Y no olvidemos que el SEO y los motores de búsqueda no hacen websockets. Para que puedas olvidarte del SEO.

Personalmente, recomendaría no hacerlo ya que hay demasiado riesgo.

No use WS para servir sitios web, utilícelo para servir aplicaciones web

Sin embargo, si tiene un juguete o un sitio web personal, hágalo . Pruébalo, sé vanguardista. Para una empresa o negocio, no puede justificar el riesgo de hacer esto.


7

Aprendí una pequeña lección (por las malas). Hice una aplicación de procesamiento de números que se ejecuta en los servicios en la nube de Ubuntu AWS EC2 (utiliza potentes GPU) y quería crear una interfaz para ella solo para ver su progreso en tiempo real.Debido al hecho de que necesitaba datos en tiempo real, era obvio que necesitaba websockets para impulsar las actualizaciones.

Comenzó con una prueba de concepto y funcionó muy bien. Pero luego, cuando queríamos que estuviera disponible para el público, tuvimos que agregar una sesión de usuario, por lo que necesitábamos funciones de inicio de sesión. Y no importa cómo se mire, el websocket tiene que saber con qué usuario trata, por lo que que tomamos el atajo de usar los websockets para autenticar a los usuarios . Parecía obvio y conveniente.

De hecho, tuvimos que pasar un tiempo en silencio para que las conexiones fueran confiables. Comenzamos con algunos tutoriales baratos de websocket, pero descubrimos que nuestra implementación no podía reconectarse automáticamente cuando se interrumpía la conexión. Todo eso mejoró cuando cambiamos a socket-io.¡Socket-io es imprescindible!

Habiendo dicho todo eso, para ser honesto, creo nos perdimos algunas características geniales de socket-io. Socket-io tiene mucho más que ofrecer, y estoy seguro de que si lo tiene en cuenta en su diseño inicial, podrá sacarle más partido. Por el contrario, acabamos de reemplazar los viejos websockets con la funcionalidad websocket de socket-io, y eso fue todo. (sin habitaciones, sin canales, ...) Un rediseño podría haber hecho todo más poderoso. Pero no tuvimos tiempo para eso. Eso es algo para recordar para nuestro próximo proyecto.

Luego comenzamos a almacenar cada vez más datos (historial de usuarios, facturas, transacciones, ...). Lo almacenamos todo en una base de datos de AWS dynamodb, y OTRA VEZ, usamos socket-io para comunicar las operaciones CRUD desde el front-end al backend. Creo que nos equivocamos de camino. Fue un error.

  • Porque poco después descubrimos que los servicios en la nube de Amazon (AWS) ofrecen excelentes herramientas de balanceo de carga / escalado para aplicaciones RESTful .
  • Ahora tenemos la impresión de que necesitamos escribir mucho código para realizar los apretones de manos de las operaciones CRUD.
  • Recientemente implementamos la integración de Paypal. Logramos que funcionara. Pero nuevamente, todos los tutoriales lo están haciendo con API RESTful . Tuvimos que reescribir / repensar sus ejemplos para implementarlos con websockets. Sin embargo, lo hicimos funcionar bastante rápido. Pero parece que vamos en contra de la corriente.

Habiendo dicho todo eso, saldremos en vivo la semana que viene. Llegamos a tiempo, todo funciona. Y es rápido, pero ¿escalará?


Solo me preguntaba, mientras intentamos tomar esta decisión nosotros mismos, ¿escaló bien con AWS?
Gabe

1
@Gabe aparentemente, el nodo puede tomar fácilmente cientos de conexiones socket-io en una instancia barata de aws. Todavía no notamos ningún problema de rendimiento. Sin embargo, uno de los efectos extraños es que las personas que visitan su sitio web una vez, pero luego dejan el sitio web abierto en una pestaña, continúan usando conexiones. (y eso sucede a menudo en teléfonos móviles). Por lo tanto, necesita al menos un tipo de mecanismo para expulsar a los usuarios inactivos. Sin embargo, todavía no me he esforzado en hacer eso, ya que nuestro rendimiento no se ve afectado en absoluto. - Entonces, todavía no era necesario escalar.
bvdb

4

Consideraría usar ambos . Cada tecnología tiene su mérito y no existe una solución única para todos.

La separación del trabajo es así:

  1. WebSockets sería el método principal de una aplicación para comunicarse con el servidor donde se requiere una sesión. Esto elimina muchos trucos que son necesarios para los navegadores más antiguos (el problema es la compatibilidad con los navegadores más antiguos que lo eliminarán)

  2. API RESTful se utiliza para llamadas GET que no están orientadas a la sesión (es decir, no se necesita autenticación) que se benefician del almacenamiento en caché del navegador. Un buen ejemplo de esto serían los datos de referencia de los menús desplegables utilizados por una aplicación web. Sin embargo. puede cambiar un poco más a menudo que ...

  3. HTML y Javascript. Estos comprenden la interfaz de usuario de la aplicación web. Por lo general, estos se beneficiarían de ser colocados en un CDN.

  4. Servicios web que utilizan WSDL siguen siendo la mejor forma de comunicación a nivel empresarial y entre empresas, ya que proporciona un estándar bien definido para el paso de mensajes y datos. Principalmente, descargaría esto a un dispositivo Datapower para usarlo como proxy en su controlador de servicios web.

Todo esto sucede en el protocolo HTTP que ya da uso de sockets seguros a través de SSL.

Sin embargo, para la aplicación móvil, los websockets no pueden volver a conectarse a una sesión desconectada ( cómo volver a conectarse a websocket después de cerrar la conexión ) y administrar eso no es trivial. Entonces, para las aplicaciones móviles , aún recomendaría REST API y encuestas.

Otra cosa a tener en cuenta al usar WebSockets vs REST es la escalabilidad . Las sesiones de WebSocket todavía son administradas por el servidor. La API RESTful, cuando se realiza correctamente, no tiene estado (lo que significa que no hay un estado del servidor que deba administrarse), por lo que la escalabilidad puede crecer horizontalmente (que es más barata) que verticalmente .


2

¿Quiero actualizaciones del servidor?

  • Sí: Socket.io
  • Sin descanso

Las desventajas de Socket.io son:

  • Escalabilidad: WebSockets requiere conexiones abiertas y una configuración de operaciones muy diferente a la escala web.
  • Learnin: No tengo tiempo ilimitado para aprender. ¡Hay que hacer las cosas!

Seguiré usando Socket.io en mi proyecto, pero no para formularios web básicos que REST hará bien.


1

Los transportes basados ​​en WebSockets (o sondeos largos) sirven principalmente para la comunicación (casi) en tiempo real entre el servidor y el cliente. Aunque existen numerosos escenarios en los que se requieren este tipo de transportes, como el chat o algún tipo de feeds en tiempo real u otras cosas, no todas las partes de alguna aplicación web deben estar necesariamente conectadas bidireccionalmente con el servidor.

REST es una arquitectura basada en recursos que se comprende bien y ofrece sus propios beneficios sobre otras arquitecturas. WebSockets se inclina más a las transmisiones / alimentaciones de datos en tiempo real, lo que requeriría que crees algún tipo de lógica basada en servidor para priorizar o diferenciar entre recursos y fuentes (en caso de que no quieras usar REST).

Supongo que eventualmente habrá más marcos centrados en WebSockets como socketstream en el futuro cuando este transporte esté más extendido y mejor entendido / documentado en forma de entrega agnóstica de tipo / formulario de datos. Sin embargo, creo que esto no significa que deba / deba reemplazar el REST solo porque ofrece una funcionalidad que no es necesariamente necesaria en numerosos casos de uso y escenarios.


-1

Esa no es una buena idea. El estándar aún no está finalizado, el soporte varía según los navegadores, etc. Si desea hacer esto ahora, tendrá que recurrir al flash o al sondeo largo, etc. En el futuro probablemente aún no hará un tiene mucho sentido, ya que el servidor tiene que admitir dejar las conexiones abiertas a todos los usuarios. La mayoría de los servidores web están diseñados para sobresalir respondiendo rápidamente a las solicitudes y cerrándolas lo más rápido posible. Diablos, incluso su sistema operativo tendría que estar ajustado para manejar una gran cantidad de conexiones simultáneas (cada conexión utiliza más puertos y memoria efímeros). Cíñete a usar REST durante la mayor parte del sitio que puedas.


Sí, la mayoría de los servidores web se destacan en HTTP. Pero node.js no es un servidor web, es una biblioteca io. Puede hacer TCP muy bien. La pregunta es básicamente decir si podemos diseñar sitios web para usar TCP en lugar de HTTP.
Raynos

Se aplican las mismas restricciones, aún se quedará sin puertos / memoria efímeros, aún limitará la cantidad de personas a las que puede atender simultáneamente y colocará una carga innecesaria en el sistema.
zeekay

sí, hay un límite, pero no creo que sea tan importante si no crea un nuevo hilo por conexión.
Raynos

Ya tengo un enchufe para cada usuario. chat global + suministro de noticias.
Harry

1
Supongo que en 2011 esta fue una gran respuesta. - Entonces, veo de dónde vienes. Pero en 2019, los websockets han madurado.
bvdb
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.