Use http status 202 for asynchronous operations

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.