Why use ASP.Net Web Api instead SignalR for internal project

Question

I know, ASP.NET Web API is designed for creating restful APIS, while SignalR is for realtime communication. So they are not competing technologies.

Imagine this: you are creating a client/server application, you are writing a desktop client that will be connect to a server to run some actions. The actions are started by the client, not by the server so both of them work.

If this is a Internal application, and you are not exposing the API, why would you use Asp.Net Web Api instead SignalR?

In both you have methods in the server that will run when the client call them. In Web Api as actions in the controllers, in signal R in the hubs. Both allow you to send parameters to the methods, and get the result in the client.

Knowing that traffic in SignalR is a little bit lower than in a Web Api (because in websocket the HTTP connection is established permanently and not create for each request), I would go for SignalR. Am I missing something?

Answer 1

Why not both?

You can use WebAPI to provide bulk data, and SignalR as an optional thing to provide updates in the data. So you would provide both functionalities, first REST to allow third parties consumers, and also offer a push technology like SignalR, or directly WebSockets, to allow callers to subscribe for changes in particular data sets.

Please keep in mind that SignalR is not only WebSockets, if fact, you need Windows 8 or Windows 2012 as server in order to use them. Otherwise, it will fallback to another transport that may not work as good as you think it does. Also, as Daniel pointed out, the scalability of SignalR is ... kind or limited, and even their own documentation states you should not use it for real time scenarios or very segmented data. SignalR is just for general broadcasting, I prefer go straight to WebSockets with the native Windows API if you are in Windows 8/2012 or a third party component.

If the client is always the action initiator, and the frequency of requests is irregular or not high, then probably REST request/response approach simplifies things a lot. If otherwise, the client does requests very often and/or with a constant rate, then go with a WebSocket, but you will need to work a little bit more.