Should I use asynchronous methods in controllers of ASP.NET Web API

Question

I was reading a book where I found that the put verb uses a same URI when we create or replace a resource while a post creates a new resource's identifier.

So in fact,

1. Does it mean that a post action in a controller (apicontroller) would always create a new instance of the resource?
2. Does it would create a new independent thread?
3. I don't need to worry to declare my method in my controller as async because it will create a new thread for any http request?
4. For a put action do I need to declare my method as async in order to avoid locks when using a web resource?

Answer 1

1) Does it mean that a post action in a controller (apicontroller) would always create a new instance of the resource?

2) Does it would create a new independent thread?

Yes. But remember The action verb on a method has nothing to do with the handling of the threads. in any call to API a new thread will be created or request will use an existing thread from the thread-pool.

3) I don't need to worry to declare my method in my controller as async because it will create a new thread for any http request?

The short answer is you should always write asynchronous methods if you care about scaling. read the long story for more detail.

4) For a PUT action do I need to declare my method as async in order to avoid locks when using a web resource?

As I said before it doesn't matter what is your action, PUT or POST. It's a good idea to use async methods specially if your making a blocking I/O operation, like accessing database.

Long story

Web services based on ASP.NET Web API, which exclusively supports REST, use the .NET Thread Pool to respond to requests. But just because services are inherently multithreaded does not make them scale when numerous requests are made simultaneously. The very reason why threads are pooled, instead of created on the fly, is because they are an extremely expensive resource, both in terms of memory and CPU utilization. For example, each thread consumes about 1 MB of stack space, in addition to the register set context and thread properties.

So once a thread has finished its work, it stays alive for about a minute, in the off-chance another request will arrive and the waiting thread can be used to service it. This means that if during the time a service request is being executed, another request arrives, an additional thread will be retrieved from the Thread Pool to service the second request. If there are no available threads, one will be created from scratch, which can take up to 500 milliseconds, during which time the request will block. If you have numerous requests for operations that take a long time to complete, more and more threads will be created, consuming additional memory and negatively affecting your service's performance.

The moral of the story is: do not block the executing thread from within a service operation.

Yet, this is precisely what happens when you perform an IO-bound task, such as when you retrieve or save data from a database, or invoke a downstream service.

If the call to the database were to take a few seconds or more, and another call comes in (even for another method) an additional thread would need to be procured from the Thread Pool.

Thanks to support for asynchronous programming in .NET 4.5 and C# 5, it is extremely easy to write asynchronous methods for an ASP.NET Web API service. Simply set the return type either to Task (if the synchronous version returns void) or to Task, replacing T with the return type of the synchronous method. Then from within the method, execute a non-blocking IO-bound async operation.

Marking the method as async allows you to await an asynchronous operation, with the compiler converting the remainder of the methods into a continuation, or callback, that executes on another thread, usually taken from the Thread Pool.

Read complete article on this Build Async Services with ASP.NET Web API and Entity Framework 6