title: How to avoid polling for time-consuming async REST requests?
body: <p>The question is on how to design a REST web service which performs time-consuming jobs (order of magnitude of several seconds and minutes).</p>
  
  <p>The fastest solution would be to proceed as follows:</p>
  
  <ol>
  <li>client sends a POST request to server (POST /job), the answer has
  HTTP status 202 and will contain the job id;</li>
  <li>client asks periodically the job status with a GET (e.g. <code>GET /job/:id/status</code>);</li>
  <li>when the job completes the client requests the results with a GET (e.g. <code>GET /job/:id/result</code>).</li>
  </ol>
  
  <p>What I don't like is step 2 because with many jobs in progress the server is unnecessarily overloaded.
  To avoid this I thought two other solutions:</p>
  
  <ul>
  <li>when the client does the first POST request, it gives also a URL which can 
  be used as a <em>callback</em> from the server. When the server ends the
  elaboration, it will notify the client at this URL with a GET/POST 
  request;</li>
  <li>the server makes available a <a href="https://en.wikipedia.org/wiki/WebSocket" rel="nofollow noreferrer">WebSocket</a> where the client can register 
  and get "notifications" on job completion;</li>
  </ul>
  
  <p>All the three solutions have aspects that I do not like:</p>
  
  <ol>
  <li><strong><em>polling:</em></strong> server overload;</li>
  <li><strong><em>callback:</em></strong> client must make a URL available to the server;</li>
  <li><strong><em>websocket:</em></strong> why introduce another "tecnology" to the REST webservice?
  Perhaps, at that point, it is better to use only websockets to do
  all requests.</li>
  </ol>
  
  <p>Are there other solutions? If no, which of the three you would consider more reliable?</p>