Return status for PATCH call on locked record with no changes

Question

I have a RESTful API that contains a typical PATCH call that allows fields to be updated under various conditions. Under some conditions (a particular status or combination of values), changes are "locked out" of a record. If a user makes a PATCH request to said record but the PATCH would not result in any changes being made (i.e. setting a field value to the same thing it already is), what status should the request return?

For example, I have a record

{
  _id: 12345,
  name: 'John Doe',
  age: 34,
  status: 'locked'
}

and I make a call

PATCH /users/12345
{
  age: 34
}

Since the status of the record is 'locked', no changes should be allowed. However, since the PATCH body states that the age value should be set to 34 which is what the value of age for that record already is, even if the record weren't locked, the request would result in no changes.

Should the request return 200 because the result of the PATCH is what the user requested in the first place or one of the 4xx codes (400, 403, or even 409) because the operation is being attempted on a "locked" record?

Answer 1

Should the request return 200 because the result of the PATCH is what the user requested in the first place or one of the 4xx codes (400, 403, or even 409) because the operation is being attempted on a "locked" record?

REST is the architectural style of the HTTP application. Caching is very important in REST. The semantics of caching in HTTP are described by RFC 7234. In particular, cache invalidation is described.

A cache MUST invalidate the effective Request URI (Section 5.5 of [RFC7230]) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error status code is received in response to an unsafe request method.

So one way to consider this question: if the client has a representation of the resource in cache, do you want to force the client to invalidate the cached entries and refetch?

Another thing you may want to consider is whether or not your locking semantics align with those described by the WebDAV specification; if they do, then returning 423 Locked may be sensible.