The header “Prefer: Respond-Async" must be defined to request a function or action execute asynchronously. If successful, the response returns 202 Accepted and includes a URI in the Location header. This should return the URI to retrieve the data from the async operation as a Location header. The following cases determine what it returns:
In the normal case, it returns your data along with 200 Ok.
When the request fails during processing, it returns the exception.
If the data has been timed out from cache, it returns 410 Gone.
If processing of the request has not completed, it returns 202 Accepted as well as the header again. The request can be resent.
There are AsynchronousRequestsSupported annotations for the function/action that can be used to determine whether a given function or action supports Asynchronous processing. For example:
<Annotations Target=”Com.Ingr.Smart3d.V1.ExecuteS3dFilter(Com.Ingr.Smart3d.V1.S3dFilter, Collection(Com.Ingr.Core.V1.ObjectHierarchy), Collection(Edm.String), Edm.String)”>
<Annotation Term=”Org.OData.Core.V1.Description” String=”Executes a Smart 3D saved filter” />
<Annotation Term=”Com.Ingr.Core.V1.DisplayName” String=”Smart 3D Filter Execution” />
<Annotation Term=”Com.Ingr.Capabilities.V1.AsynchronousRequestsSupported” Bool= “true” />
This shows that the ExecuteS3dFilter action supports Asynchronous requests.
So for the following request:
The Prefer: Respond-Async header is set, which is how to tell the API that the request needs to be processed asynchronously. The return status for this call should be 202 accepted. This status indicates that it has received the message and is currently processing the request. Inside the Location Header of the response should be the URI needed to retrieve the data from the completed asynchronous transaction. It will look similar to this:
Using this URI should return the data fully processed as it would appear if the original request was sent synchronously.