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.
