From d598b13da11c779aea7c11522be3572a66d9c4f5 Mon Sep 17 00:00:00 2001
From: Ralf Handl Data Modification Request on an existing resource or an Action Request invoking an action bound to an existing resource MAY require optimistic concurrency control. Services SHOULD announce this via annotations with the terms
Core.OptimisticConcurrency
in OData-VocCore and Capabilities.NavigationRestrictions
(nested property OptimisticConcurrencyControl
) in OData-VocCap.
If optimistic concurrency control is required for a resource, the service MUST include an ETag
header in a response to a GET
request to the resource, and MAY include the ETag in a format-specific manner in responses containing that resource.
If optimistic concurrency control is required for a resource, the service MUST include an ETag
header in a response to a GET
request to the resource, and MAY include the ETag in a format-specific manner in responses containing that resource, see for example OData-JSON, section “Control Information: etag
(odata.etag
)”.
The presence of an ETag
header in a response does not imply in itself that the resource requires optimistic concurrency control; the ETag may just be used for caching and/or conditional GET
requests.
If an ETag value is specified in an If-Match
or If-None-Match
header of a Data Modification Request or Action Request, the operation MUST only be invoked if the If-Match
or If-None-Match
condition is satisfied.
If the client does not specify an If-Match
request header in a Data Modification Request or Action Request on a resource that requires optimistic concurrency control, the service responds with a 428 Precondition Required
and MUST ensure that no observable change occurs as a result of the request. Clients can attempt to disable optimistic concurrency control by specifying If-Match
with a value of *
. Services MAY reject such requests.