3

I THINK I understand the basic principle of an asynchronous POST method from a high level view point. The big advantage is that the caller gets a quick response, even though the processing of the data from the POST might not be completed yet.

But I don't really understand how this applies to a GET method. The response needs to contain the data, so how can there BE a response before processing is completed? Why have an API with a GET request handler that utilizes asynchronous methods?

I don't think it matters for this general type of question, but I'm writing in C# using Web API.

Lou Franco
  • 87,846
  • 14
  • 132
  • 192
Steve Wash
  • 986
  • 4
  • 23
  • 50
  • It is to free up the current thread whilst IO/network operations go ahead asynchronously. GET or POST makes no difference to that. In either case, you are asking for something from a web server and you get some form of response. Whether it has a payload or not is irrelevant. – ManoDestra May 26 '16 at 19:29
  • 1
    Are you sure you know what await does? Many people think it starts some work on a background thread which leads to confusion. – usr May 26 '16 at 19:33

3 Answers3

3

On the network there is no such thing as an async HTTP call. It's just data flowing over TCP. The server can't tell whether the client is internally sync or async.

the caller gets a quick response

Indeed, the server can send the response line and headers early and data late. But that has nothing to do with async IO or an async .NET server implementation. It's just some bytes arriving early and some late.

So there is no difference between GET and POST here.

why ... utilize asynchronous methods?

They can have scalability benefits for the client and/or the server. There is no difference at the HTTP level.

usr
  • 168,620
  • 35
  • 240
  • 369
  • Sure, but a server could (1) start an asynchronous process, (2) return data to the client, (3) close the connection, and then (4) complete the asynchronous work. I *think* that's what the OP is asking about. – Aaron Brager May 26 '16 at 19:57
  • 1
    @AaronBrager I now think we both misunderstood. – usr May 26 '16 at 19:59
  • Let me clear up some confusion, as I guess the question is vague. There are two things that got me to ask this question. One is the use of async endpoints in the AccountController of the Identity MVC Sample code. I know the people who wrote that code know more then I do, I just didn't get the purpose of making so many of the endpoints async. The other is the use of EntityFramework ToListAsync in an endpoint as I've seen in various examples. But if the response can be sent AS the data is retrieved, it makes more sense. – Steve Wash May 26 '16 at 23:56
  • @SteveWash OK, my answer appears to apply then. These usages of async have zero impact on the client. The client does not get a single byte any faster. Also, there is no parallel or "fire and forget" work being done. This is a case of using async IO for scalability.; I don't think you know what await does. await waits for something to complete that is already started. It does not start anything. Does that help? – usr May 27 '16 at 08:45
  • Definitely helps, particularly the explanation of scalability. I surmise that the scalability improves because a thread is returned to the app pool. Bottom line, there is some benefit to server performance in using async and ToListAsync when retrieving data even for relatively small datasets. Particularly for high traffic websites. I think the inaccurate mental image many people have of the thread "hanging around awaiting for something to complete" makes this hard to grasp. – Steve Wash May 27 '16 at 09:57
  • Almost all usages of async IO on the server have zero benefit and cost dev time. Making AccountController async is completely pointless and harms code quality. Low volume operations do not benefit from async since they tie up very few threads. I guess the team wants to demonstrate the async capabilities of the framework. If you're interested in that you might like http://stackoverflow.com/a/25087273/122718 Why does the EF 6 tutorial use asychronous calls? http://stackoverflow.com/a/12796711/122718 Should we switch to use async I/O by default? – usr May 27 '16 at 10:00
1

So the app can do other things that don't need the data.

If you implement a GET as synchronous (and let's say you are on a bad network, where it takes 20 seconds to get it), you can't

  1. Show progress
  2. Allow the user to cancel
  3. Let them initiate other GETs
  4. Let them use other parts of the app

EDIT (see comments): The server wants to respond asynchronously for mostly the same reason (to give up the thread). Actually getting the data might be asynchronous and take some time -- you wouldn't want to block the thread for the whole time.

Lou Franco
  • 87,846
  • 14
  • 132
  • 192
  • 1
    It sounds like you're talking about why a *client* would do it asynchronously. (Your answer is great if that's the question.) My interpretation, though, was that the OP was asking about why the *server* would respond to a GET request asynchronously. – Aaron Brager May 26 '16 at 19:31
  • 1
    I've read it three times now and I can't tell. I assume they will pick the answer that make the most sense to them. – Lou Franco May 26 '16 at 19:33
  • I was intending to ask why the SERVER would respond asynchronously. Thanks for pointing out this important distinction. Your response makes great sense, for the client. – Steve Wash May 26 '16 at 19:44
0

It doesn't make any sense if you're building a RESTful API, in which GET should return a resource (or a collection) and be idempotent (not make any changes).

But if you're not following those principles, a GET request could perform some work asynchronously. For example, GET /messages/3 could return the message to the client, but then asynchronously do other work like:

  • mark the message as read
  • send a push notification to the user's other clients indicating that the message is read
  • schedule a cronjob 30 days in the future to delete the message
  • etc.

None of these would be considered a RESTful API, but are still used from time to time.

Aaron Brager
  • 65,323
  • 19
  • 161
  • 287