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