Thanks for clarifying, so this isn't about concurrency but rather handling updates based on stale data.
I think this really should be up to the client to decide what is required, since there will be cases where the 'nonconcurrent' behavior is in fact expected. In terms of HTTP that would be by using the If-Unmodified-Since header, but yes, it requires server side checks although one can be clever and use a common updated field on all resources.
Typically you want concurrency checks to be based on something managed by the database (rowversion and xmin being the go to options) rather than timestamps, because timestamps can lie. IME at least, last modified timestamps are usually more like a record of "has this record logically changed" rather than a literal "has the row been modified," so it's not unusual to have things like internal data operations that modify a row without setting the updated timestamp. The ETag header [0] is meant for carrying this info, but TBH I don't think I've ever actually seen it used. Most of the time resources that need concurrency checks end up carrying around a version property or something similar.
The back end really has to make the determination of what resources need protection from concurrent updates and enforce it, because of the above and because if you're going to let the client decide whether or not to participate in concurrency checks you really end up with no protection at all.
I think this really should be up to the client to decide what is required, since there will be cases where the 'nonconcurrent' behavior is in fact expected. In terms of HTTP that would be by using the If-Unmodified-Since header, but yes, it requires server side checks although one can be clever and use a common updated field on all resources.