0

Via GET I receive a representation of an entity which includes a version attribute.
Now I want to PATCH that entity, do I include this very version attribute and let the server decide to either accept or decline (if it was altered in the meantime) my PATCH request? Same logic would apply to PUT requests I believe.

Should the server give the client the chance to know that it might overwrite "old" data?
Or is it in the nature of REST that "newer equals newer"?

Are there any best practices or thoughts on this topic?

What I found so far is the ability for the client to control the behaviour, via the test operation of the PATCH method. See baeldung-json-patch-test-operation

ch1ll
  • 419
  • 7
  • 20
  • 1
    This sounds like a use-case for `ETag` and `If-Match`. This is basically a solved problem. Servers can choose to require inclusion of the header (`428 error`) or make it opt in (use `412` only when the etag is wrong) – Evert Mar 02 '23 at 20:56
  • I found the `test` operation in the `PATCH` method, this seems like another (maybe more recent? As PATCH was only introduced in 2010?) approach. As a Server I could always check for the test operation and reject it otherwise? What I get from your comment is that, it is always a case-by-case decision on how this update mechanism is handled? – ch1ll Mar 03 '23 at 06:02

0 Answers0