locked
Creating async types on a web API that will run with an asp.net web site RRS feed

  • Question

  • User-2146352328 posted

    Hi.

    I want to ask if it is a viable solution to use async functions , await and tasks , when creating a web api that will run through an MVC or simple asp.net web site.

    As I mostly deal with simple asp.net sites I know that using threads , at least inside of a web site is a big no no. I'm not sure if that will also apply to a web api usage.

    The web API is somewhere in a server and the web site is in another server. They are not commonly connected.

    Thanks in advance.

    Monday, March 21, 2016 12:45 PM

Answers

  • User36583972 posted

    Hi sapator,

    Use asynchronous methods in the API are feasible. DoNET Framework 4.5 adds two new keywords to simplify asynchronous programming, on top of the task-based programming model introduced in .NET Framework 4 with the System.Threading.Tasks namespace.

    •async: This modifier marks a method or a lambda expression as asynchronous. When you are going to make asynchronous calls by using the await keyword, you need to add the async keyword to the method's signature.

    •await: This operator yields control until a task completes. By using this modifier, you don't have to create callback functions anymore. The compiler does the necessary work to transform your code into an asynchronous call and also handles the necessary conversion to return T, instead of Task<T>. As a result, the code is really simpler to write and easier to understand. However, you can also return Task<T> whenever needed.

    You can refer the following tutorials and get some new ideas.

    The .NET 4.5 async/await feature in Promise and Practice:

    https://www.simple-talk.com/dotnet/.net-framework/the-.net-4.5-asyncawait-feature-in-promise-and-practice/

    Web API, Async and Performance in an ASP.NET MVC application:

    http://www.dotnetcurry.com/aspnet-mvc/948/webapi-async-performance-aspnet-mvc-application

    Best Regards,

    Yohann Lu

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, March 22, 2016 6:11 AM
  • User753101303 posted

    Not sure what was avoided but it was likely incorrect ways of doing that rather than really async as a goal.

    AFAIK it makes sense if you can really have some stuff parallelized (such as making multiple web service calls to build your page) or it helps with scalability (uses specialized ways to wait for I/O rather than waiting on a worker thread).

    If you don't send mutliple requests in parallel or you don't have a high traffic site it is unlikely you'll see a real difference.

    On the other side it is made quite easy with async/await. Do something that works first and you'll always be  able to enhance later. If not already done just make sure to not explicitely use things such as HttpWebResponse or JObject all over the place but to use a thin layer to ease changing your implementation at a later time.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, March 22, 2016 11:56 AM

All replies

  • User753101303 posted

    Hi,

    Try perhaps http://blog.tonysneed.com/2013/03/22/async-services-asp-net-web-api-entity-framework-6/ for a start and feel free to narrow down the discussion. I'm still quite unsure about the exact problem you want to discuss (calling from MVC, writing the API, or being able to either do remote calls or local calls if deployed on the same server or maybe some other issue ?)

    Monday, March 21, 2016 1:33 PM
  • User36583972 posted

    Hi sapator,

    Use asynchronous methods in the API are feasible. DoNET Framework 4.5 adds two new keywords to simplify asynchronous programming, on top of the task-based programming model introduced in .NET Framework 4 with the System.Threading.Tasks namespace.

    •async: This modifier marks a method or a lambda expression as asynchronous. When you are going to make asynchronous calls by using the await keyword, you need to add the async keyword to the method's signature.

    •await: This operator yields control until a task completes. By using this modifier, you don't have to create callback functions anymore. The compiler does the necessary work to transform your code into an asynchronous call and also handles the necessary conversion to return T, instead of Task<T>. As a result, the code is really simpler to write and easier to understand. However, you can also return Task<T> whenever needed.

    You can refer the following tutorials and get some new ideas.

    The .NET 4.5 async/await feature in Promise and Practice:

    https://www.simple-talk.com/dotnet/.net-framework/the-.net-4.5-asyncawait-feature-in-promise-and-practice/

    Web API, Async and Performance in an ASP.NET MVC application:

    http://www.dotnetcurry.com/aspnet-mvc/948/webapi-async-performance-aspnet-mvc-application

    Best Regards,

    Yohann Lu

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, March 22, 2016 6:11 AM
  • User-2146352328 posted

    Hello all.

    I have used async methods before but in winforms.

    Never used on a web API.

    So by reading the examples I see that it is not a problem to use async.

    The exact issue I'm investigating is WEB API ASYNC METHOS --- Web - Iphone - Android .

    On Web app I am calling the API like this:

        Dim response As JObject
                Using httpWebResponse As HttpWebResponse = CType(httpWebRequest.GetResponse(), HttpWebResponse)
                    Using Reader = New StreamReader(httpWebResponse.GetResponseStream(), Encoding.UTF8)
                     
                        Dim r = Reader.ReadToEnd()
                        response = JObject.Parse(r)
                    End Using
                End Using

    Is this viable?

    Thanks.

    Tuesday, March 22, 2016 9:58 AM
  • User753101303 posted

    Hi,

    You also have http://www.asp.net/web-api/overview/advanced/calling-a-web-api-from-a-net-client that could make this a bit cleaner  and which support async as well... You can install from https://www.nuget.org/packages/Microsoft.AspNet.WebApi.Client

    Tuesday, March 22, 2016 10:07 AM
  • User-2146352328 posted

    ΟΚ.

    So basically pinpointing the problem, from my view is, if it is proper to use async calls from the WEB APPLICATION.

    I mean, if the web api will work with the async without problems, is it wise to use async :

    await.client.postasync

    or await.client.getasync on a web applications.

    In asp.net simple apps this has been avoided like the plaque. Has anything changed.

    Tuesday, March 22, 2016 11:19 AM
  • User753101303 posted

    Not sure what was avoided but it was likely incorrect ways of doing that rather than really async as a goal.

    AFAIK it makes sense if you can really have some stuff parallelized (such as making multiple web service calls to build your page) or it helps with scalability (uses specialized ways to wait for I/O rather than waiting on a worker thread).

    If you don't send mutliple requests in parallel or you don't have a high traffic site it is unlikely you'll see a real difference.

    On the other side it is made quite easy with async/await. Do something that works first and you'll always be  able to enhance later. If not already done just make sure to not explicitely use things such as HttpWebResponse or JObject all over the place but to use a thin layer to ease changing your implementation at a later time.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, March 22, 2016 11:56 AM
  • User-2146352328 posted

    Thanks.

    Jobject is a list but we are contacting tests right now, so we use it.

    Wednesday, March 23, 2016 7:57 AM