Why use ASP.Net Web Api instead SignalR for internal project
asp.net-mvc, asp.net-web-api, c#, signalr, websocket
Solution
The most compelling reason to go with a framework like web api is convenience. One advantage is content negotiation based on the request header. If you ask for json it will automatically return you json. Same with xml or other standard formats. It also has a great formatter system that enables you to support custom needs. It's also light on configuration and easy to set up.
You could perfectly well create your own framework or even use MVC, WebForms or any other way to expose a web endpoint, but you would typically hard code the format in the response (json, xml, html etc)
Anyway, at the end of the day you just need something that will speak in terms of http - request -> response.
Problem
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?