Delayed Response for Completing HTTP Requests
A pattern for using
202 Accepted to support delayed HTTP responses
In cases where the HTTP response will be delayed (due to extended processing, multi-step workflow, etc.) you can use the Accepted pattern to return
202 Accepted from the service (along with additional metadata) until the work is actually completed (e.g.
200 OK) or has failed (e.g.
HTTP 400/500 response).
- Application State Diagram
- Semantic Descriptors
- accepted (semantic), Delayed Response resource
- acceptedRecord (semantic), A single accepted record
- cancel (semantic), Requested cancel resource
- completed (semantic), Requested completed resource
- completedURL (semantic), URL of the completed status resource
- dateCreated (semantic), Indicates the date/time (UTC) this delayed response was first created).
- dateEstimated (semantic), Indicates the date/time (UTC) this this delayed request is expected to complete.
- dateUpdated (semantic), Indicates the last date/time (UTC) this delayed response was modified).
- description (semantic), Human-readable text that describes this document.
- doCancel (idempotent), Request to cancel this outstanding delayed task (using DELETE)
- failed (semantic), Requested failed resource
- failedURL (semantic), URL of the failed status resource
- goAccepted (safe), Navigate to the delayed response resource
- goCompleted (safe), Navigate to the completed resource
- goFailed (safe), Navigate to the failed resource
- goHome (safe), Navigate to the home resource
- home (semantic), Home resource
- identifier (semantic), unique identifier for this delayed response.
- percentCompleted (semantic), A value (0-100) of completion.
- refresh (semantic), A value (in milliseconds) that represents the refresh interval
- status (semantic), Indicates document status (pending, working, completed, failed)
- URL (semantic), URL of this delayed response document