jonathonmcmurray / qwebapi Goto Github PK

Current implementation is synchronous. HTTP spec allows for async handling via status code 202 (https://tools.ietf.org/html/rfc7231#section-6.3.3)

This should be implemented something like follows:

1. Request comes in to function that is "registered" as asynchronous (when defining API)
2. Request is added to a queue table which will track details of (at least)
   • job ID
   • function & args
   • status (waiting, in progress, done)
3. 202 response sent to initial request with Location header for queued resource e.g.

HTTP/1.1 202 Accepted
Location: /queue/12345

4. Client can query /queue/12345 for updated status on job
5. A some time after request has been added to queue, it will be processed & status updated to done
6. When client queries /queue/12345 for completed job, response will be status 303 See Other (https://tools.ietf.org/html/rfc7231#section-6.4.4) with location of finished response e.g.

HTTP/1.1 303 See Other
Location: /thing/97865

7. Client can query new location & get response for their original query

To allow API process to remain responsive to intermediate requests to /queue etc., processing should likely be done by another process, connecting via IPC & querying the queue table to get a job to do. However, this is considered beyond the scope of this module. Within webapi, we will provide the functionality to build the queue & send status updates to incoming queries to /queue.