rest - Use http status 202 for asynchronous operations

Question

I am writing a REST API for a service that will accept user contributed data. I would like to keep all operations completely asynchronous, this includes PUT, POST, DELETE and perhaps even GET requests. My idea is to receive the request, process it enough to ensure it is a valid request and then pass a HTTP 202 accepted response along with a url where the data will eventually be available and a token so that subsequent requests can be matched to processed data. If the request is invalid then I will send a HTTP 400.

The client will then be responsible to check the url I provided them at some time in the future and pass along the token. If the data is available I return a normal 200 or 201 but if I am still processing the request I will send another 202 indicating the processing hasn't completed. In case of errors processing the data I will send 4xx or 5xx status as necessary.

The reason I want to do this is so I can dump all valid requests into a request pool and have workers pull from the queue and process requests as they are available. Since I don't know the pool size or number of workers available I can't be certain that I can get to requests fast enough to satisfy the 30 second limit of Google App Engine.

My question is: am I perverting REST by processing requests in this manner? Browsers, for instance, seem to require immediate responses to requests. For my HTML pages I plan to respond with the structured page and then use AJAX to process the data requests.

I'm mostly interested in any opinions or experience in processing data using REST in this manner.

Answer 1

I think that your solution is fine, the Http status 202 is the proper response to use in this specific case indicating that the request has been accepted for processing, but the processing has not been completed.

What I would slightly change in your workflow are the Http status of the subsequent requests.

As you said, the 202 response should return a Location header specifying the URL that client should use to monitor the status of its previous request.
Calling this Check-the-status-of-my-process URL, instead of returning a 202 in case of process pending, I would return:

1. 200 OK when the requested process is still pending. The Response should describe the pending status of the process.
2. 201 Created when the processing has been completed. The Response in case of GET/PUT/POST should contain the Location to the requested/created/updated resource.