is
Jon Skeet
Correct API approach for long processing time
I am making an HTTP web API that's mainly fed by a database. Simplified, the db contains userobjects.
These objects have a last_online (when the user was online) and last_checked (the last time I checked the userobject).
Checking the userobject can take from 3 to 30 seconds. When the last_checked time is less than 10 minutes then everything's okay; API call returns 200 and the userobject.
But I want to reprocess the userobject when the data is staler than 10 minutes. Obviously I can not have my API return sit there and wait.
What is the right approach to HTTP APIs that (sometimes) need to return data from long running processes?
One fairly "old-school" way of handling this would be to return a continuation token - basically a job ID saying, "Check this periodically; sooner or later it'll come back with a result." Given that even 30 seconds is quite a long time, you might want to give back a continuation token even in the normal "checking" situation.
More modern alternatives would be web sockets or a hanging get... it really depends on what your client use cases are.
See more on this question at Stackoverflow