Responses for Async Processing

[Eric Williams]

Love this show.  Long time listener, first time caller ...

I have an endpoint that accepts a file upload and then en-queues the file for further async out-of-band processing.  The processing will do what it needs and then come back to update the status of the file etc.

When the upload is done and file dropped on the queue we send back a location header where the entity will be available and have some conneg wrapped around that endpoint so that they can get the metadata (processing status, availability etc) on the file or get the file itself.  The processing time is a little bit undeterministic but is usually pretty quick.  For the most part I'd be fine with a client coming back and asking for status in few seconds but I want to communicate to them via the http response that the file isn't ready and the client should "wait until timestamp" or "wait for x units of time".

Assuming augmenting the response body in the metadata response is off the table what would be some http mechanisms to look at for the poll-for-status side of the equation?  I was looking at some of the If-* headers but I'm not quite sure if those are appropriate.  Maybe Retry-After, but nothing is broken we're just waiting some someone else.

Thanks

Eric

Lolo, MT

[darrel...@gmail.com]

Eric,

From RFC 7231 [1]

“Servers send the "Retry-After" header field to indicate how long the user agent ought to wait before making a follow-up request.”

There is no inference that retry-after is limited to dealing with failures.  In fact the spec explicitly mentions using it with redirects also.  I’ve used it with 202 before and have not seen any negative impacts.

You might also want to look at this https://github.com/tavis-software/Tavis.Status for some related ideas.  It is a media type designed to describe the current status of a long running request.

Darrel

[1] https://tools.ietf.org/html/rfc7231#section-7.1.3

Sent from Surface

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Chris Mullins]

When you say "pretty quick" and "non-deterministic" I start to think, "Is polling really the right idea?" and "How non-deterministic does he mean?" What's the P50, P90, P99, P99.9 and P100 cases look like? 

Are these clients, or services making the request to your API? 

If they're services, this seems like a reasonable candidate for Web Hooks. Easy setup, easy tear-down, well explored patterns, and very responsive.  

If they're clients, how fast do they need to know it's done? If the answer is "immediately!" (users are a notoriously impatient bunch!) this seems like some combination of:

1. Push notifications (Azure Notifications Service, Amazon SNS), as this will get to IOS / Android / Desktop devices. 

2. Long Polling 

3. Web Socket. 

#2 and #3 are fairly resource costly from a Service Perspective. Sometimes the user latency win is worth it. 

I should add that I despise traditional "Is it done? Is it done?" polling to the point (nearly) of (simulated) physical illness. 

Cheers,

Chris

[Eric Williams]

Thanks Darrel - I ended up going to 202 approach for now.