REST API - Concurrency Check Using ETags

If ETag is not present in the request header, what is the general practice? Do we just return a BadRequest?

RFC 6586 defines 428 Precondition Required:

The 428 status code indicates that the origin server 
requires the request to be conditional.

Do we also include the absence of ETag in the response to inform the client?

Yes, just as you would for any other client error in HTTP.

Except when responding to a HEAD request, the server 
SHOULD send a representation containing an explanation 
of the error situation, and whether it is a temporary 
or permanent condition.

RFC 6585 includes this example

<html>
  <head>
     <title>Precondition Required</title>
  </head>
  <body>
     <h1>Precondition Required</h1>
     <p>This request is required to be conditional;
     try using "If-Match".</p>
  </body>
</html>

Is there any approach where-in clients can be informed of actions that require specific headers?

I don't see any standard mechanism to communicate this to general purpose components.

The usual mechanism would, I believe, to communicate that information in response to an OPTIONS request:

A server generating a successful response to OPTIONS SHOULD send any header fields that might indicate optional features implemented by the server and applicable to the target resource (e.g., Allow), including potential extensions not defined by this specification. The response payload, if any, might also describe the communication options in a machine or human-readable representation.

What Wikipedia says on ETag:

An ETag is an opaque identifier assigned by a Web server to a specific version of a resource found at a URL. If the resource representation at that URL ever changes, a new and different ETag is assigned.

And then

If the resource representation at that URL ever changes, a new and different ETag is assigned

With that said, it's should be clear that on GET requests, there should be no ETag presented, or it should not be taken into consideration by web server.
However, a response to GET request should contain the ETag which should be utilized on next entity's modification.

Actually, it can be presented in GET requests according to MDN if caching is involved, but as I can see from your question, it's not the case here?

Here you can read how ETag is utilized in Azure Table Storage. Note that ATS allows to omit ETag. In that case an ordinary updated will be performed. And that makes sense: allowing to omit ETag means more flexibility; programmer can decide where concurrency will be handled — by Azure Table Storage (utilizing ETag) or on the client side level, where calling side checks (or at least should odso) that requests do not run into concurrency issues.

Speaking of your RESTful api, that means that there is no general practice. You should decide are clients able to utilize your API without Etag or not, and if not — return appropriate error code. To notify client side that ETags should be used, you can return them with responses.

REST API - Concurrency Check Using ETags

Related

Recent Posts