¿Cuáles son las trampas de usar Websockets en lugar de RESTful HTTP?

Con HTTP RESTful tiene un sistema de solicitud/respuesta sin estado donde el cliente envía la solicitud y el servidor devuelve la respuesta.

Con WebSockets tiene un sistema de paso de mensajes con estado (o potencialmente con estado) donde los mensajes se pueden enviar de cualquier manera y el envío de cualquier mensaje es menor que con una solicitud/respuesta HTTP RESTful.

Las dos son estructuras bastante diferentes con diferentes fortalezas.

Las principales ventajas de un WebSocket conectado son:

1. Comunicación bidireccional. Por lo tanto, el servidor puede notificar al cliente cualquier cosa en cualquier momento. Por lo tanto, en lugar de sondear un servidor en algún intervalo regular para ver si hay algo nuevo, un cliente puede establecer un WebSocket y simplemente escuchar cualquier mensaje proveniente del servidor. Desde el punto de vista del servidor, cuando ocurre un evento de interés para un cliente, el servidor simplemente envía un mensaje al cliente. El servidor no puede hacer esto con HTTP simple.

2. Menor sobrecarga por mensaje. Si anticipas que fluye mucho tráfico entre el cliente y el servidor, entonces hay una sobrecarga más baja por mensaje con un WebSocket. Esto se debe a que la conexión TCP ya está establecida y solo tiene que enviar un mensaje en un socket ya abierto. Con una petición HTTP REST, primero tiene que establecer una conexión TCP que es varios back y forths entre el cliente y el servidor. Luego, envía una solicitud HTTP, recibe la respuesta y cerrar la conexión TCP. La solicitud HTTP necesariamente incluirá algunos gastos generales, como todas las cookies que están alineadas con ese servidor, incluso si no son relevantes para la solicitud en particular. HTTP / 2 (especificación HTTP más reciente) permite cierta eficiencia adicional en este sentido si está siendo utilizado tanto por el cliente como por el servidor porque una sola conexión TCP se puede usar para más que una sola solicitud/respuesta. Si trazó todas las solicitudes / respuestas a nivel TCP solo para hacer una solicitud/respuesta https REST, te sorprendería cuánto está pasando en comparación con solo enviar un mensaje a través de un WebSocket ya establecido.

3. Mayor Escala en algunas circunstancias. Con una sobrecarga más baja por mensaje y sin encuestas de clientes para averiguar si algo es nuevo, esto puede conducir a una escalabilidad adicional (mayor número de clientes que un servidor determinado puede servir). También hay desventajas en la escalabilidad de WebSocket (ver debajo).

4. Conexiones con estado. Sin recurrir a las cookies y los ID de sesión, puede almacenar directamente el estado en su programa para una conexión determinada. Si bien se ha hecho mucho desarrollo con conexiones sin estado para resolver la mayoría de los problemas, a veces es simplemente más simple con conexiones con estado.

Las principales ventajas de una solicitud/respuesta HTTP RESTful son:

1. Soporte Universal. Es difícil conseguir más universalmente soportado que HTTP. Si bien WebSockets disfruta de un soporte relativamente bueno ahora, todavía hay algunas circunstancias en las que el soporte WebSocket no está disponible regularmente.

2. Compatible con más entornos de servidor. Hay entornos de servidor que no permiten procesos de servidor de larga duración (algunas situaciones de alojamiento compartido). Estos entornos pueden admitir solicitudes HTTP, pero no pueden admitir conexiones WebSocket de larga ejecución.

3. Escala Más Alta en algunas circunstancias. El requisito de WebSocket para un socket TCP conectado continuamente agrega algunos nuevos requisitos de escala a la infraestructura del servidor que las solicitudes HTTP no exigen. Por lo tanto, esto termina siendo un espacio de compensación. Si las ventajas de WebSockets no son realmente necesarias o no se utilizan de manera significativa, entonces las solicitudes HTTP podrían escalar mejor. Definitivamente depende del perfil de uso específico.

4. Para una única solicitud/respuesta , un único HTTP request es más eficiente que establecer un WebSocket, usarlo y luego cerrarlo. Esto se debe a que la apertura de un WebSocket comienza con una solicitud/respuesta HTTP y luego, después de que ambas partes hayan acordado actualizar a una conexión WebSocket, se puede enviar el mensaje WebSocket real.

5. Apátrida. Si su trabajo no se complica por tener una infraestructura sin estado, entonces un mundo sin estado puede hacer que el escalado sea mucho más fácil (simplemente agregue más procesos de servidor detrás de un balanceador de carga).

6. Cacheable automáticamente. Con la configuración correcta del servidor, las respuestas http se pueden almacenar en caché por navegador o por proxies. No existe tal mecanismo integrado para las solicitudes enviadas a través de WebSockets.

Así que, para abordar la forma en que hizo la pregunta:

¿Cuáles son las trampas de usar websockets en lugar de HTTP RESTful?

1. A gran escala (cientos de miles de clientes), es posible que tenga que hacer algunos servidores especiales funcionan para soportar un gran número de WebSockets conectados simultáneamente.

2. Todos los clientes o conjuntos de herramientas posibles no admiten WebSockets o solicitudes realizadas a través de ellos al mismo nivel que admiten solicitudes HTTP.

3. Algunos de los entornos de servidor menos costosos no admiten los procesos de servidor de larga ejecución necesarios para admitir WebSockets.

Si es importante para tu aplicación recuperar las notificaciones de progreso para el cliente, puede usar una conexión http de larga duración con el progreso continuo que se envía o puede usar un WebSocket. El WebSocket es probablemente más fácil. Si realmente solo necesita el WebSocket para la duración relativamente corta de esta actividad en particular, entonces puede encontrar que el mejor conjunto general de compensaciones viene utilizando un WebSocket solo para la duración del tiempo en que necesita la capacidad de enviar datos al cliente y luego usar solicitudes http para la solicitud/respuesta normal actividad.