Question:
I've been told that best practice states that long running http web requests should be turned into shorter asynchronous requests with a mechanism for polling for completion.
Why?
Important Distinction:
I'm working on a web service API. It's not meant to be called by browsers (which would hang on the load) but by rich clients (which call remote services asynchronously anyways) and scripts (which can do the same asynchronous trick)
Motivation:
I'd like to know because I'm trying to make decisions as to when a request should be made asynchronous, what is the cutoff point? I'm working on a web based API that has requests which take anywhere from 0.001 seconds to 400 seconds (and everywhere in between) depending on the request (not the parameters but which actual method they're calling).
I could make everything asynchronous (except for the poll for command completion) but that complicates the work done by API clients (i.e. getting results from requests, polling for completion, etc.)
As far as I know I could also make everything synchronous since the same amount of work is getting done either way so it seems the load will be similar.
Furthermore, all the web services I've used seem to follow a hybrid model so they must be making the decision somehow.
The only way I could really answer this question is to know why that best practice exists.
Asynchronous APIs do not block. Every synchronous call waits and blocks for your results to come back. This is just a sleeping thread and wasted computation.
If you need something to happen, send of an asynchronous request and do further computation when the request returns. This means your thread sits idle and can pick up other work.
Asynchronous requests is the way to scale to thousands of concurrent users.
but that complicates the work done by API clients
This is just a matter of API design. Generally you can call your web API with a callback to handle this. No polling is required.
WebService.Call("someMethod" (data) -> {
// do something when data returns.
});