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.Htt
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:
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.