MVC controller actions vs Web API vs SignalR – what to use?

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?

1. First, the MVC controller actions. ASP.NET MVC framework is a layer on top of good old ASP.NET and it was originally built support and traditional synchronous web development architecture where controller action is generating HTML as a response to HTTP requests and accepting HTTP form posts when the whole page is reloaded.  However, it’s also possible to call a controller action asynchronously from javascript passing JSON object as a parameter and getting JSON in response. As MVC is built on top of ASP.NET it inherits ASP.NET paradigms like session support. HTTP protocol is stateless by it’s definition, however ASP.NET is supporting user session state.  Being statefull also means thread affinity.

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

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.
MVC AJAX controller actions are simply just the another flavor of the regular controller actions. The only difference is that they returning and accepting JSON objects. So, if you have a predominantly traditional MVC multi-page  application, especially if you application relies on Web Forms user authentication and supports user session then MVC controller actions are probably your best bet. You will not have any problems with authenticating user on loging page, storing user profile details in session and then later on using ajavascript to asynchronously load data here and there on some pages. That would probably the easiest and most effortless scenario.
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.