Hace unos días Quora “me pidió” que contestara a alguien que preguntaba si el servicio “API Gateway de AWS soporta otro protocolo diferente de REST”. A pesar del error conceptual en la pregunta — creo que sabes cual es — , la respondí muy rápido, pero Sergio hablará muy pronto, y con más detalle, sobre API Gateway. ¡Así que estáte atento! La cuestión es que esta pregunta me inspiró a escribir el post de hoy y a hacer una breve comparación entre REST (HTTP) y WebSocket.

REST no es el protocolo

Más que una comparación “REST vs WebSocket”, se trata de una comparación HTTP versus WebSocket (ws). Pues, como bien recuerdas, REST (Representational State Transfer) es un patrón, o estilo de diseño de arquitectura y no un protocolo de transporte. El protocolo HTTP es una implementación de la arquitectura REST.

¿Qué es una API de REST?

De forma muy breve y resumida — puedes encontrar más información aquí, o aquí, una API de REST es un conjunto de reglas que permiten la comunicación entre aplicaciones web. REST utiliza el protocolo HTTP y muchas de sus características como parte de la estructura de su API. De hecho, alguien dijo hace tiempo que “REST es la web y la web es REST”. Estarás de acuerdo o no, pero a dia de hoy es el estilo más utilizado. :)

¿Qué es un WebSocket?

Un Websocket es un protocolo de comunicaciones que proporciona canales de comunicación “full-duplex” sobre una misma conexión TCP. Es el mismo concepto de los clásicos sockets de UNIX, pero en la Web, y con la idea de facilitar la transferencia de datos en tiempo real del servidor, y para el servidor. Siendo una comunicación bidireccional, el servidor puede enviar la información directamente al cliente en el momento de la conexión. Como bien sabes, REST no lo hace de forma fácil. Aunque haya en el mercado frameworks muy potentes que saben lidiar con REST y backends en tiempo real.

¿Qué diferencia hay entre REST y WebSocket?

Como hemos dicho anteriormente, REST es un estilo de arquitectura y WebSocket un protocolo, portanto tiene sentido si comparemos HTTP con WebSocket. Estas son algunas de las diferencias:

Comunicación

Con WebSockets envías al servidor mensajes de cadenas simple con datos, y el servidor procesa los datos y las respuestas. La comunicación es más eficiente que HTTP si nos centramos en el tamaño del mensaje, y en la velocidad, especialmente para mensajes de gran tamaño, ya que en HTTP, por ejemplo, tienes que enviar los headers en cada petición. Esto suma bytes. Además en REST, tienes los recursos en URLs y métodos de HTTP. Lo que significa que para cada petición, obtienes una respuesta.

Puede ser buena idea observar los benchmarkings realizados por David Luecke para comparar el rendimiento de HTTP vs WebSockets. Verás que para más de 50 peticiones concurrentes, ¡Websockets pueden ser el 50% más rápidos que HTTP! Esto significa que en muchos casos y según las necesidades de tu proyecto, WebSockets pueden ser más rápidos que las APIs de HTTP tradicionales.

Stateless vs Stateful

Otra de las diferencias más importantes para mí entre los dos, es que que WebSockets son protocolos stateful, mientras las conexiones HTTP son stateless. Esto quiere decir que WebSockets crean una conexión que se mantiene viva en el servidor hasta que el socket se cierre y se intercambian los mensajes de forma bidireccional. Mientras que en las conexiones HTTP, en que una petición significa una respuesta — válida o no -, el acceso desde diferentes servidores no interrumpe su funcionamiento, lo que desde mi punto de vista es ideal, por ejemplo para microservicios. Pues, cualquier servidor puede gestionar cualquier petición y no es necesario sincronizar cualquiera de los estados compartidos, excepto la base de datos.

Conclusión

Para terminar, y aunque sea posible, creo que implementar un sistema 100% WebSocket puede ser mala idea en el sentido de que tengas que implementar funcionalidades que ya existen en REST y HTTP. ¿Reinventar la rueda? Entonces, ¿por qué no utilizar WebSockets para las transacciones de datos en tiempo real — por ejemplo para un chat — y REST para el caso contrario?

Pienso que a la hora de seleccionar la mejor opción es también importante tener en cuenta ciertos detalles, como por ejemplo que en las conexiones HTTP, el navegador limita el número de peticiones concurrentes, pero que no hay limitaciones en el número de mensajes que una conexión por WebSocket puede enviar, o recibir. También recomiendo estar atento a métricas relacionadas con la transferencia de datos, el tiempo de carga y la escalabilidad. Y, para tenerlo todo mucho más controlado, ¿por qué no crear sistemas que permitan seleccionar de forma fácil los protocolos de transporte más adecuados para cada situación?

¿En qué casos utilizas Websockets envés de HTTP o vice-versa?

Fotografía: pixabay.com

Originally published at www.itdo.com on January 8, 2019.