Polling
If an API operation can be considered as a long running task (LRT) and the API Consumer can track its progress, the response to the LRT MUST return, in the case of success, the 202 Accepted status code together with an application/hal+json
representation of a new task-tracking resource.
Task Tracking Resource
The task-tracking resource SHOULD convey the information about the status of an asynchronous task.
Retrieval of such a resource using the HTTP GET Request Method SHOULD be designed as follows:
Task is Still Processing
Return 200 OK and representation of the current status.
Task Successfully Completed
Return 303 See Other together with HTTP Location Header with URI or a outcome resource.
Task Failed
Return 200 OK and
application/problem+json
with the problem detail information on the task has failed.
Design Note
The polling (task-tracking) operation requires a clear adaptation on the API Consumer side:
Polling requests frequency depend on the type of operation and specific latency of thre resource.
The identification of the resource has to be correlated along the series of polling requests. The API Consumer has to be able to save this ID and the API Producer has to be able to identify the progress of the operation with that ID.
A security problem can be raised if a non-authorized client retrieves the response for a different resource ID. The authorization data and tasks in progress have to be strongly correlated and controlled to avoid consistency issues.
Example
Initiate the polling task
Poll the task status: In progress
Poll the task status: Finished
Poll the task status: Failure
Last updated