title: Determining synchronous vs. asynchronous in web applications
body: <p><strong>Question:</strong></p>
  
  <p>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.</p>
  
  <p>Why?</p>
  
  <p><strong>Important Distinction:</strong></p>
  
  <p>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)</p>
  
  <p><strong>Motivation:</strong></p>
  
  <p>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).</p>
  
  <p>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.)</p>
  
  <p>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.</p>
  
  <p>Furthermore, all the web services I've used seem to follow a hybrid model so they must be making the decision somehow.</p>
  
  <p>The only way I could really answer this question is to know why that best practice exists.</p>