¿Es el rendimiento la única razón para no usar SignalR (websockets) completamente en lugar de una API REST tradicional?

Esas dos tecnologías tienen un propósito muy diferente.

• REST es para llamadas normales a una API, siendo el cliente un actor activo del intercambio. Cuando el cliente necesita encontrar las coordenadas GPS de una dirección, el cliente inicia la llamada a la API y espera hasta que reciba las coordenadas, o se produce un error, o transcurre un tiempo de espera.

• Los sockets web son para todo lo que necesita hacer las cosas de manera opuesta. Por ejemplo, cuando uso un sitio web de intranet que me muestra en tiempo real los registros y el rendimiento de diferentes servidores, el cliente puede ser pasivo y esperar hasta que el servidor le envíe un mensaje de registro o rendimiento recientemente publicado. métricas.

La diferencia es clara: en el primer caso, el cliente decide cuándo necesita una información específica; en el segundo caso, el cliente simplemente espera ser contactado, y puede que no sepa cuándo sería.

De alguna manera, ambos son intercambiables: puede implementar sockets web cuando no los necesite (es decir, el cliente llamará al servidor a través de sockets web en lugar de hacer una llamada REST) y puede usar sondeo o sondeo largo como un sustituto a los sockets web (dado que se usó con éxito durante años hasta que los sockets web se hicieron tan populares).

Pero su intercambiabilidad tiene un costo:

• Cuando usas sondeo o sondeo largo en lugar de sockets web, a menudo estás desperdiciando ancho de banda.

• Cuando usa sockets web para hacer lo que se puede hacer a través de la API web, mantiene abiertas todas las conexiones de todos los clientes activos, lo que puede que no sea lo que realmente desea. Para un sitio web pequeño donde espera tener como máximo 5 clientes al mismo tiempo, esto no es un problema. Para un servicio como Amazon AWS, esto no sería fácil de resolver técnicamente.

No uses sockets web cuando no los necesites. Para obtener las coordenadas GPS de una dirección, no obtengo nada al abrir la conexión de sockets web, hacer la llamada, esperar una respuesta y cerrar la conexión: REST satisface mis necesidades para tales escenarios.

• Si se encuentra comprobando repetidamente y con frecuencia la información a través de una llamada REST a un servicio, esto puede ser una buena señal de que debe pasar a los sockets web. De manera similar, Stack Overflow reduce el uso de ancho de banda al usar sockets web, ya que ayuda a las personas a no gastar su tiempo presionando F5 en la página de inicio para ver si tienen nuevos mensajes.

• Si descubre que abre conexiones de sockets web, úselas para hacer una sola llamada y luego ciérrelas, o si sus conexiones permanecen abiertas pero el servidor envía algo al cliente solo a petición del cliente, cambie REST.

Además, los sockets web aún tienen un soporte limitado y no siempre son fáciles de implementar. Si bien SignalR facilita la implementación, esto no significa que no tendrá dificultades para implementarlo en otros idiomas / contextos / entornos. Con REST, eso es fácil: puede ser una llamada curl o una función similar disponible en todos los idiomas principales. Con los sockets web, no puede estar seguro de cuánto tiempo le tomará a un cliente usar [ingrese el nombre de un idioma que aún no conozca aquí].

He usado sockets web en varios proyectos en .NET, Python y node.js.

• En .NET, no fue demasiado difícil, pero aún así, todavía pasé unos días tratando de resolver algunos problemas crípticos, como la conexión que se interrumpió tan pronto como se abrió. (Esto fue antes de SignalR; nunca probé SignalR). También utilicé WCF en modo web sockets, que tampoco estuvo exento de problemas (pero creo que WCF siempre viene con problemas).

• En node.js, esto era factible, pero tuve que cambiar dos veces las bibliotecas hasta que encontré una que funciona. Creo que he pasado al menos una semana tratando de hacer un sockets web Hello World.

• En Python, lo intenté una vez, pasé dos o tres días y lo abandoné. Nunca funcionó.

Compare esto con REST: el único problema que se puede encontrar con un nuevo lenguaje / marco es saber cómo enviar archivos POST o recibir una respuesta binaria muy grande. Recuerdo que pasé unas horas buscando soluciones para algunos idiomas. Sin embargo, unas pocas horas para un caso especial no son nada en comparación con días o semanas para un simple Hola Mundo.

Solo mis 2 centavos ...

Creo que no se trata realmente de rendimiento o de cualquier tipo. Se trata de estándares. REST es un estándar e IMHO tiene las siguientes ventajas:

• Las solicitudes HTTP son fáciles de usar. Todo el mundo puede usar rápidamente una API REST. Diablos, incluso puede abrir el navegador y escribir una URL para ver los datos, ¿qué tan interactivo puede ser?
• (Casi) cualquier lenguaje de programación puede usarlo. Es una especie de interfaz universal. La interfaz con SignalR desde un lenguaje exótico parece menos obvia.
• Tiene un buen soporte de herramientas, como enlace
• Es una buena "interfaz" para depurar. Puede monitorear fácilmente los mensajes entrantes y salientes directamente en el navegador, ver los datos, etc. Con websockets y bibliotecas personalizadas, no es tan obvio, tiene que registrar todo explícitamente.