We are currently discussing my team and I will be interested in other views. Suppose we have a RESTful web service, the role of which is to annotate documents using various algorithms and analysis services. The main interaction is clear: we have a resource, which is a collection of documents; the client sends a new document to the collection, returns the URI of the new document, then can GET to docURIreturn the document or GET {docURI}/metadatato see the general metadata,{docURI}/nefor named objects, etc. The problem is that some analyzes can take a lot of time. Suppose the client GETS the metadata URI before the analysis is completed, as he wants to show partial or additional results in the user interface. Repeating the GET in the future may give more results.
The solutions we discussed include:
- maintaining an HTTP connection until all analyzes are done (which does not seem scalable)
- using
content-lengthand accept-range
headers to get incremental content (but we donโt know in advance how long the final content will be) - providing Atom for each resource, so the client subscribes to update events, and not just a getting resource (it seems too complicated and, possibly, resource hunger if there are many active documents)
- only returning GET is all that is available at that time (but it still leaves the client problem knowing when we will finally finish) [edited to remove the link to idempotency after comments].
Any opinions or suggestions on alternative ways to handle long-lived or asynchronous interactions in a RESTful architecture?
Jan
source
share