Si te encuentras con algo que te causa duda puedes comentarlo y trataremos de ayudarte lo más rápido posible.
Solución:
¿Por qué no los dos?
Puede usar WebAPI para proporcionar datos masivos y SignalR como algo opcional para proporcionar actualizaciones en los datos. Por lo tanto, proporcionaría ambas funcionalidades, primero REST para permitir a los consumidores de terceros, y también ofrecería una tecnología push como SignalR, o directamente WebSockets, para permitir que las personas que llaman se suscriban para cambios en conjuntos de datos particulares.
Tenga en cuenta que SignalR no es solo WebSockets, de hecho, necesita Windows 8 o Windows 2012 como servidor para poder usarlos. De lo contrario, recurrirá a otro transporte que puede no funcionar tan bien como cree. Además, como señaló Daniel, la escalabilidad de SignalR es… amable o limitada, e incluso su propia documentación establece que no debe usarlo para escenarios en tiempo real o datos muy segmentados. SignalR es solo para transmisión general, prefiero ir directamente a WebSockets con la API nativa de Windows si está en Windows 8/2012 o en un componente de terceros.
Si el cliente es siempre el iniciador de la acción y la frecuencia de las solicitudes es irregular o no es alta, entonces probablemente el enfoque de solicitud/respuesta REST simplifica mucho las cosas. Si, por el contrario, el cliente realiza solicitudes con mucha frecuencia y/o con una tasa constante, vaya con un WebSocket, pero tendrá que trabajar un poco más.
SignalR es excesivo en la mayoría de los casos para Solicitud/Respuesta, iría con REST. Y luego use SignalR para actualizaciones automáticas.
Para actualizaciones automáticas, puede abstraer SignalR con esta biblioteca (soy el autor) https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy
En los pros y los contras, debe agregar la limitación y la escalabilidad de cada solución. No recuerdo las cifras, pero SigalR necesita muchos recursos para mantener la conexión, especialmente con el navegador antiguo (5000 clientes es la limitación predeterminada en IIS). Mientras que con WebApi, se enfoca en cuántas solicitudes tendrá en lugar de cuántos clientes se conectarán (incluso si no hacen nada).
WebApi también es más fácil de escalar. Con SignalR, deberá configurar un plano posterior que puede convertirse en un cuello de botella.
En SignalR, si asigna los usuarios y la conexión, será mejor que elija una solución que se ajuste a los requisitos futuros si planea agregar más servidores.
Reseñas y valoraciones del artículo
Agradecemos que quieras favorecer nuestra faena añadiendo un comentario y dejando una puntuación te estamos eternamente agradecidos.