[biaachmonkie]

Then you'd have to implement a version or hash field on the object and verify it before updating and fail on mis-match and handle the version mis-match error on the client and re-retrieve and update again.

  GET: {version: 1, field: [1,2,3]}
  PATCH: {version: 1, field: [1,2,3,4]} # succeeds 
  PATCH: {version: 1, field: [1,2,3,5]} # fails with HTTP 409 response
  # Client displays some sort of warning that the update failed, GETs the object again and merges the new state from the server with it's state and can retry the update
  GET: {version: 2, field: [1,2,3,4]}
  PATCH: {version: 2, field: [1,2,3,4,5]} # succeeds

[zepolen]

Sure, though prefer to use If-Unmodified-Since or If-Match as those are standard and caches support them properly. Another issue is how do you support both removing `field` from the document or setting it to null? Sending `field: null` will only work for one of those cases.

Likewise the moment you start to do this architecture is the moment you fail to scale. You're putting unnecessary load on your backend by forcing the client to refetch the resource in order to make another update, not to mention the scenario where a lot of clients are trying to add items to field

> GETs the object again and merges the new state from the server

At some critical point all those clients will start blocking each other as they constantly make PATCHes that fail and reGET only to fail again because another client managed to make their PATCH before them. The problem made worse by network latency and app code.

Patches that work with changesets will support a much higher concurrent write load as the concurrency/serialization is done server side, and the changesets will be small rather than the entire value. Under load all the individual requests may take longer to complete they will all ultimately succeed. Concurrency conflicts may still occur but they will be a couple orders of magnitude less frequent.

Depending on the type of update, eg. adding items to a list, this is what you want. Removing / updating values otoh may be classed as something you'd prefer to have constraint check via If- headers.