title: Etags used in RESTful APIs are still susceptible to race conditions
body: <p>Maybe I'm overlooking something simple and obvious here, but here goes:</p>
  
  <p>So one of the features of the Etag header in a HTTP request/response it to enforce concurrency, namely so that multiple clients cannot override each other's edits of a resource (normally when doing a PUT request). I think that part is fairly well known.</p>
  
  <p>The bit I'm not so sure about is how the backend/API implementation can actually implement this without having a race condition; for example:</p>
  
  <p>Setup:</p>
  
  <ul>
  <li>RESTful API sits on top of a standard relational database, using an ORM for all interactions (SQL Alchemy or Postgres for example).</li>
  <li>Etag is based on 'last updated time' of the resource</li>
  <li>Web framework (Flask) sits behind a multi threaded/process webserver (nginx + gunicorn) so can process multiple requests concurrently.</li>
  </ul>
  
  <p>The problem:</p>
  
  <ul>
  <li>Client 1 and 2 both request a resource (get request), both now have the same Etag.</li>
  <li>Both Client 1 and 2 sends a PUT request to update the resource at the same time. The API receives the requests, proceeds to uses the ORM to fetch the required information from the database then compares the request Etag with the 'last updated time' from the database... they match so each is a valid request. Each request continues on and commits the update to the database.</li>
  <li>Each commit is a synchronous/blocking transaction so one request will get in before the other and thus one will override the others changes.</li>
  <li>Doesn't this break the purpose of the Etag?</li>
  </ul>
  
  <p>The only fool-proof solution I can think of is to also make the database perform the check, in the update query for example. Am I missing something?</p>
  
  <p>P.S Tagged as Python due to the frameworks used but this should be a language/framework agnostic problem. </p>