Over the course of a last few years Microsoft unleashed two new web development frameworks: Web API and SignalR, both are suitable for asynchronous communications between web client and web server. And, of course, we still have MVC controller actions that can be used for asynchronous communications too and can accept and return JSON objects. So, what’s the difference between these three frameworks and what are the best patterns and practices for using these?
2. Web API is looking very similar to MVC: there are controllers, routes and filters. However, Web API is tracing it’s roots from the different source: WCF. Because of that, Web API doesn’t have a dependency from ASP.NET and could potentially be hosted on a web server which is different from IIS or could be self-hosted in application. Web API is stateless, asynchronous (Task<T> could be used as a return type for actions) and there are no thread affinity. Web API is very aware of HTTP verbs (like GET, PUT, DELETE, etc) and so it’s completely restful. In fact, the default routing setup for Web API doesn’t include action into the route.
3. SignalR is a newest kid on the block. “R” stand for “realtime”. SignalR is a realtime communication framework built on top of the WebSoket specification, however it does fallback to classic HTTP when websockets are not supported by client or server. The major advantage of this framework is that it’s keeping a persistent connection from browser to the server thus allowing for realtime communication and pushing messages from server to client. Just like Web API, SignalR doesn’t have a dependency from ASP.NET and IIS hosting environment, SignalR is built on top of OWIN (Open Web Interface for .NET)/Katana framework which is liberating SignalR from IIS hosting requirement. SignalR is also stateless by design and it’s not aware of ASP.NET user session.
So, which framework should we select for asynchronous message exchange between browser and a web server? As usual, the answer is not obvious and depends on the application architecture and functional requirements.
If you have a true SPA (single page application) and/or you planning to use the same backed for mobile application or expose it to third party developers, then Web API would be the most reasonable architecture. Just be aware of the absence of the user session (you’ll need to maintain the session on the client, not on the server) and plan for securing the Web API calls with a token (instead of the forms authentication cookie), although with a little coding it’s possible to make forms authentication work with Web API as well, but it’s not a recommended practice.
And if your web application needs to take an advantage of the real time messaging, pushing messages from server to client and multi-casting messages to multiple clients at once (which is great for multi-user collaborative application or a messaging application) then SignalR would be a great choice. SignalR can be used together with Web API just fine, so some functionality in application which is not realtime and doesn’t require persistent connection could be served by Web API.