WebSockets - API
API - Definición
API, una abreviatura de Application Program Interface, es un conjunto de rutinas, protocolos y herramientas para crear aplicaciones de software.
Algunas características importantes son:
La API especifica cómo deben interactuar los componentes de software y las API deben usarse al programar componentes de interfaz gráfica de usuario (GUI).
Una buena API facilita el desarrollo de un programa al proporcionar todos los componentes básicos.
REST, que generalmente se ejecuta a través de HTTP, se usa a menudo en aplicaciones móviles, sitios web sociales, herramientas de mashup y procesos comerciales automatizados.
El estilo REST enfatiza que las interacciones entre los clientes y los servicios se mejoran al tener un número limitado de operaciones (verbos).
La flexibilidad se proporciona mediante la asignación de recursos; sus propios identificadores de recursos universales (URI) únicos.
REST evita la ambigüedad porque cada verbo tiene un significado específico (GET, POST, PUT y DELETE)
Ventajas de Web Socket
Web Socket resuelve algunos problemas con REST o HTTP en general:
Bidireccional
HTTP es un protocolo unidireccional donde el cliente siempre inicia una solicitud. El servidor procesa y devuelve una respuesta, y luego el cliente la consume. Web Socket es un protocolo bidireccional en el que no existen patrones de mensajes predefinidos, como solicitud / respuesta. Tanto el cliente como el servidor pueden enviar un mensaje a la otra parte.
Duplex completo
HTTP permite que el mensaje de solicitud vaya del cliente al servidor y luego el servidor envía un mensaje de respuesta al cliente. En un momento dado, el cliente está hablando con el servidor o el servidor está hablando con el cliente. Web Socket permite que el cliente y el servidor se comuniquen de forma independiente.
Conexión TCP única
Por lo general, se inicia una nueva conexión TCP para una solicitud HTTP y se termina después de recibir la respuesta. Es necesario establecer una nueva conexión TCP para otra solicitud / respuesta HTTP. Para Web Socket, la conexión HTTP se actualiza mediante un mecanismo de actualización HTTP estándar y el cliente y el servidor se comunican a través de esa misma conexión TCP durante el ciclo de vida de la conexión Web Socket.
El gráfico que se muestra a continuación muestra el tiempo (en milisegundos) que se tarda en procesar N mensajes para un tamaño de carga útil constante.
Aquí están los datos sin procesar que alimentan este gráfico:
El gráfico y la tabla que se muestran arriba muestran que la sobrecarga de REST aumenta con la cantidad de mensajes. Esto es cierto porque muchas conexiones TCP deben iniciarse y terminarse y muchas cabeceras HTTP deben enviarse y recibirse.
La última columna muestra en particular el factor de multiplicación de la cantidad de tiempo para cumplir con una solicitud de REST.
El segundo gráfico muestra el tiempo necesario para procesar una cantidad fija de mensajes variando el tamaño de la carga útil.
Aquí están los datos sin procesar que alimentan este gráfico:
Este gráfico muestra que el costo incremental de procesar la solicitud / respuesta para un punto final REST es mínimo y la mayor parte del tiempo se dedica al inicio / terminación de la conexión y respetando la semántica HTTP.
Conclusión
Web Socket es un protocolo de bajo nivel. Todo, incluido un patrón de diseño de solicitud / respuesta simple, cómo crear / actualizar / eliminar la necesidad de recursos, códigos de estado, etc., se construirá sobre él. Todos estos están bien definidos para HTTP.
Web Socket es un protocolo con estado, mientras que HTTP es un protocolo sin estado. Las conexiones de Web Socket pueden escalar verticalmente en un solo servidor, mientras que HTTP puede escalar horizontalmente. Existen algunas soluciones patentadas para el escalado horizontal de Web Socket, pero no se basan en estándares. HTTP viene con muchas otras ventajas, como almacenamiento en caché, enrutamiento y multiplexación. Todos estos deben definirse sobre Web Socket.