OCAPI Batch Requests
An OCAPI batch request is a multipart HTTP request that can contain up to 50 subrequests. Each subrequest (part) must operate on a single resource; subrequests that specify multiple ids (for example,
'/products/(p1,p2...)') are forbidden.
Batch requests reduce network overhead by reducing the overall amount of information transmitted and by reducing the number of calls you have to make. For example, to build an application screen, you can construct a single large multipart batch request instead of constructing numerous smaller individual OCAPI requests.
The HTTP method used for the batch request as a whole must be POST or OPTIONS. Each subrequest can specify a different HTTP method if necessary.
Each batch request has a main header section. In this section, you must include a
Content-Type header that specifies a type (multipart/mixed) and a boundary separator that is used to delimit each subrequest. For example:
Every header included in the main header section of the batch request is implicitly inherited by each subrequest. The query parameters of the main batch request are also implicitly inherited by each subrequest.
Each subrequest, however, is conceptually a complete OCAPI request with its own resource path, header section, and request body. If needed, a subrequest can override its inherited headers and its inherited query parameters.
To specify the behavior of subrequests and to define the mapping between requests and responses, you must specify the following headers where appropriate:
|Specifies the HTTP method used to access the resource.
|Specifies the base resource path. The value of this header is combined with value of the
x-dw-resource-path-extension header to provide a complete resource path.
|Specifies an extension for the value of the base path, as specified by the
x-dw-resource-path header. This header is optional if the base resource path already represents a valid OCAPI resource.
|Specifies an ID of the subrequest. This header value is used to map a subrequest to a subresponse.
|Specifies the status code of a single subresponse.
Batch requests are supporting CORS. Allowed expose headers and origins are mentioned in OCAPI settings for each client ID. To access them, it’s mandatory to send a batch request for a specific client in a context, either of a specific site or global. There are several possibilities to pass a client identification:
- Client ID as query parameter
- Client ID as x-dw-client-id header
- OAuth access token via Authorization header
- JWT via Authorization header
Subrequests in a batch request body adhering to the standard defined in Multipart Media Type. This approach means that the header section in a Multipart subrequest has to follow directly after the Multipart boundary. The header section and the Multipart body section have to be separated by two subsequent newline characters.
Correct formatted subrequest.
Wrong formatted subrequest. Only one newline after header section.
Wrong formatted subrequest. Two newlines after boundary lead to an empty header section.
This example shows how you can access multiple resources of the same type:
This example shows how you can access resources of different types:
The site context for each request can be defined in
x-dw-resource-path-extension. If no site context is given in these headers, the one from the main request is taken. This implies, that the site context from the main request can be overwritten by the resource path headers.
The size of the batch request body is limited to 5 MB. The maximum number of subrequests is 50.
|Thrown if the request content type isn’t multipart/mixed or specifies no boundary.
|Thrown if the query string for the request or a subrequest is invalid.
|Thrown if the authorizarion header has not the format Authorization: Bearer ...
|Thrown if the HTTP method in the request header or subrequest header is invalid.
|Thrown if the request body is invalid.
|The token sent via Authorization: Bearer header is invalid or expired.
|Thrown if the batch request was sent with an HTTP method other than POST or OPTIONS.
|Thrown if no client identification was sent with the main request (either as client ID or authorization token).
|Thrown if at least one subrequest has no HTTP method.
|Thrown if at least one subrequest has no resource path.
|Thrown if the batch request contains more than 50 subrequests.
|Thrown if the batch request body is larger than 5 MB.
|Thrown if at least one subrequest is a multiple-ID resource call.
|Thrown if the given origin isn’t mentioned in the OCAPI settings for the accessing client.
|Thrown if the given client identification isn’t known to the account manager.
|Thrown if the request was sent in the context of an unknown site name.