¿API Websocket para reemplazar la API REST?

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

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.

• http://www.danielbaulig.de/socket-ioexpress/

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

• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

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

• http://blog.pusher.com/2011/6/21/backbone-js-now-realtime-with-pusher

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

• http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
• http://addyosmani.com/blog/building-spas-jquerys-best-friends/
• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Usando Backbone con DNode:

• http://quickleft.com/blog/backbone-without-ajax-part-ii
• http://quickleft.com/blog/backbone-without-ajax-part-1
• http://sorensen.posterous.com/introducing-backbone-redis
• https://github.com/cowboyrushforth/minespotter
• http://amir.unoc.net/how-to-share-backbonejs-models-with-nodejs
• http://hackerne.ws/item?id=2222935
• http://substack.net/posts/24ab8c

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 .

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.

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.

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á?

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 .

¿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.

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.

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.