Most approriate HTTP return code when record locked for update due to invalid data

Question

Context

Typical restful CRUD service, including PATCH method, whose API validates fields (eg the "name" field may not contain digits).

However, data in the database (from backdoor ETL load) could be "invalid" according to API (eg "name" is loaded in as "John Smith 3rd").

Business requirement: The record is blocked for update until all fields are valid.

Example: If user sends patch for say "address", but "name" in the DB is invalid, an error condition should be returned with a message something like "name" (as stored in the database) is invalid. A valid value for "name" must also be provided

Question:

What is the most appropriate HTTP return code?

---

My thoughts are:

Chosing between 4xx "it's your fault" and 5xx "it's our fault", 5xx is the best fit because the request per se is valid. Proof of that is that if the data were not invalid at the server, the exact same request would be accepted - so the request is structurally and content-wise valid, so it is not a 4xx.

412 Precondition Failed at first glance seems a possible fit, in the sense that the pre-condition of the data in the database being all valid is not met, but the purpose of 412 is data locking related and should be used when the condition defined by the If-Unmodified-Since or If-None-Match headers is not fulfilled.

Of the 5xx family, none fit except 500 Internal Server Error unexpected condition was encountered and no more specific message is suitable with a response body that contains the error description.

---

Note: GET on the resource is still allowed. It is expected that after receiving such an error, the client (user) will GET the whole record, examine the field mentioned in the error, and fix the problem with the field-the-client-doesn't-care-about-but-is-made-to-care. Or give up.

My preference is to prevent bad data being injected into the database, but that is what the business wants - dump everything in, warts and all.

Answer 1

Since this is a violation of a business rule (the format of a name does not conform to business requirements), the most appropriate code is probably 422 Unprocessable Entity.

On developer.mozilla.org

---

The HyperText Transfer Protocol (HTTP) 422 Unprocessable Entity response status code indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions.

This is exactly what is happening in your case, you do understand the request, its syntax is valid, but you reject the operation because of a business rule in place.