This is one of these thing written that we never pay attention:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Section 24: If-Match

The If-Match request-header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that one of those entities is current by including a list of their associated entity tags in the If-Match header field. Entity tags are defined in section 3.11. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used, on updating requests, to prevent inadvertent modification of the wrong version of a resource. As a special case, the value “*” matches any current entity of the resource.

Well done Nunes

The only thing to keep in mind when using timestamp-based checking is that it’s only limited to the next second. So, if the resources in your application are likely to change more often than once a second, then timestamp-based conditional headers are not the right choice.

The only negative point is that when sharing unmodified-check responsibility with the client, a non conforming one might break your application.

The following code should use the received ETag as in the example:

product = entry.at(uri)
product.update new_representation

But most up-to-date rest-called client API’s will simply ignore it, and execute it anyways, breaking our implementation. Thats why I still on a crusade against http apis, looking for REST client ones.

ETag and PUT is also a good solution when you are unsure your last request went through. Suppose the first PUT attempt got connected, you sent the request, but got no response back from the server.

Great post!

Tomas