Most Web API 2.0 methods I've seen return IHttpActionResult, which is defined as an interface that "defines a command that asynchronously creates a System.Net.Http.HttpResponseMessage".
I'm a little confused about what's going on when a method is returning async Task<IHttpActionResult>.
Why would you use one over the other? Or are these functionally identical - isn't IHttpActionResult already asynchronous?
The difference between using IHttpActionResult and async Task<IHttpActionResult> is whether any of your code utilizes the async and await feature. Many libraries like Entity Framework provide async versions of methods (e.g. SaveChangesAsync) that provide a slight performance increase. However, there are pitfalls to using async with Web API, so unless you understand many of the idiosyncrasies it is prudent to stick to the synchronous API.
Steven Cleary has a lot of information on his blog about the idiosyncrasies of async and await. To get started I advise looking at Don't block on async code.
Your action may return an IHttpActionResult which performs the action asynchronously when the framework calls its ExecuteAsync.
But if you must first make some other async calls before creating and returning the result, then you're forced to change the signature to async Task<IHttpActionResult>. That's all it is.
If your controller action code doesn't use await then you can switch back to the simpler signature. However, the result you return will still be asynchronous.
To be clear, in both cases, you are using asynchronous code.
The performance benefit is that - provided all calls to the deepest level are async - a web server thread is not blocked during disk or network I/O, your server can handle more requests with fewer resources.
Think carefully before calling Wait or Result on a Task, or creating a Task yourself within ASP.NET code.
Two legitimate reasons to hand-code, intentional multi-threading or parallelism for web server code are:
