Question

We have a REST service that calls out to a system process that could possibly take upwards of 2 minutes to process. Since on clients I don’t want to wait 30-seconds to 2 minutes for a response back from the server, can I return a 202 to the client to notify that it’s in processing but doesn’t necessarily need to wait for the process to finish?

Is there a safe way to handle this? (I’m sure there is thread safety issues here, especially if the service could get hit with tons of requests at once, so creating tons of threads may not be the solution.)

Something we are exploring is using batch processing that checks every 5 minutes or so to check the db for reports that need generating (which is what the system process is for), but I was curious about this possibility.

Thanks in advance

EDIT
The final product is actually a PDF report that gets generated, and then emailed to the user. I am mostly trying to get around having to wait the ~2 minutes of waiting for the service response back on the consuming client.

Answer 1

I think the immediate return of a 202 from the service is fine as it’s acknowledging the successful receipt of the request to create a pdf.

Your plan to log pending requests in the db and process them in batches makes sense to me. If each pdf file is ticked off as ‘done’ once the pdf has been sent without error (like a message queue / worker role system) I think it will work fine.

If you didn’t want to go the db route your service endpoint could spawn another async job then return a 202. That way the pdf job is started immediately and the client gets an immediate response – but this does seem a bit messy IMO.

edit: re-reading your question – I don’t think you can return the 202 and keep on processing within the same function. Once you have returned, that’s it (unless you spawned another async job, as above).