Skip to main content

I found the suggestions from this blog reasonable: REST and long-running jobsREST and long-running jobs.

To summarize:

  1. Server returns code "202 Accepted"The server responds to job requests with 202 Accepted and the "Location"Location header field set to athe URI for client to checkof the status monitor, e.g. "/queue/12345"/queue/12345.
  2. Until the processingjob finishes, the server responds to status queriesrequests with "200 OK"200 OK and some response datarepresentation showing job status.
  3. After the processingjob finishes, the server responds to status queriesrequests with "303 See Other"303 See Other and "Location" containing URIthe Location header field set to the finalURI of the job result, e.g. /stars/97865.
  4. After the status monitor is deleted manually by the client or automatically by the server, the server responds to status requests with respectively 404 Not Found or 410 Gone.

I found the suggestions from this blog reasonable: REST and long-running jobs.

To summarize:

  1. Server returns code "202 Accepted" with the "Location" header set to a URI for client to check the status, e.g. "/queue/12345".
  2. Until the processing finishes, server responds to status queries with "200 OK" and some response data showing job status.
  3. After the processing finishes, server responds to status queries with "303 See Other" and "Location" containing URI to the final result.

I found the suggestions from this blog reasonable: REST and long-running jobs.

To summarize:

  1. The server responds to job requests with 202 Accepted and the Location header field set to the URI of the status monitor, e.g. /queue/12345.
  2. Until the job finishes, the server responds to status requests with 200 OK and some representation showing job status.
  3. After the job finishes, the server responds to status requests with 303 See Other and the Location header field set to the URI of the job result, e.g. /stars/97865.
  4. After the status monitor is deleted manually by the client or automatically by the server, the server responds to status requests with respectively 404 Not Found or 410 Gone.
Grammar.
Source Link

I found the suggestions from this blog reasonable: REST and long-running jobs.

To summarize:

  1. ReturnServer returns code "202 Accepted" with the "Location" header set to a URI for client to check the status, e.g. "/queue/12345".
  2. Until the processing finishes, server respondresponds to status queryqueries with "200 OK" and some response data showing job status.
  3. WhenAfter the processprocessing finishes, server respondresponds to status queryqueries with "303 See Other" and "Location" containscontaining URI to the final result.

I found the suggestions from this blog reasonable: REST and long-running jobs.

To summarize:

  1. Return code "202 Accepted" with the "Location" header set to a URI for client to check the status, e.g. "/queue/12345".
  2. Until the processing finishes, server respond to status query with "200 OK" and some response data showing job status.
  3. When the process finishes, server respond to status query with "303 See Other" and "Location" contains URI to the final result.

I found the suggestions from this blog reasonable: REST and long-running jobs.

To summarize:

  1. Server returns code "202 Accepted" with the "Location" header set to a URI for client to check the status, e.g. "/queue/12345".
  2. Until the processing finishes, server responds to status queries with "200 OK" and some response data showing job status.
  3. After the processing finishes, server responds to status queries with "303 See Other" and "Location" containing URI to the final result.
Better answer than comment anyway, and fixed a typo in the OK status code
Source Link

Sorry, I can't add comment yet.

I found the suggestions from this blog reasonable: REST and long-running jobs.

To summarize:

  1. Return code "202 Accepted" with the "Location" header set to a URI for client to check the status, e.g. "/queue/12345".
  2. Until the processing finishes, server respond to status query with "202"200 OK" and some response data showing job status.
  3. When the process finishes, server respond to status query with "303 See Other" and "Location" contains URI to the final result.

Sorry, I can't add comment yet.

I found the suggestions from this blog reasonable: REST and long-running jobs.

To summarize:

  1. Return code "202 Accepted" with the "Location" header set to a URI for client to check the status, e.g. "/queue/12345".
  2. Until the processing finishes, server respond to status query with "202 OK" and some response data showing job status.
  3. When the process finishes, server respond to status query with "303 See Other" and "Location" contains URI to the final result.

I found the suggestions from this blog reasonable: REST and long-running jobs.

To summarize:

  1. Return code "202 Accepted" with the "Location" header set to a URI for client to check the status, e.g. "/queue/12345".
  2. Until the processing finishes, server respond to status query with "200 OK" and some response data showing job status.
  3. When the process finishes, server respond to status query with "303 See Other" and "Location" contains URI to the final result.
Source Link
Loading