Suppose I have an API that has two calls:
/list
/detail
And the /list is used to get a list of header representations of some object I have (maybe ID and title) and the /detail gets the full information for one of the objects from the list. The /list has no parameters and returns a JSON array. The /detail is a post request and is supposed to be given a JSON object as the post body parameter, and that JSON object has some template it is supposed to follow that will allow the server to figure out which object the user wants the detailed information for.
Further suppose that I have a website that interacts with the API and uses the API calls to produce a website.
The question I have is if someone calls the /detail without an ID, or with an ID that does not exist should the response be a 400 or a 500? The argument for making the response a 400 error code is the fact that from the server's point of view the request is malformed, therefore the request is bad.
If we take the perspective of the human website user, however, the request was probably perfectly reasonable from the perspective of the browser, but the problem was the server provided incorrect data (in the first call), or the server provided a webpage that built a mangled JSON object to send to the server (or any other variety of problems that could exist due to bugs on the server, or bugs in the webpage that the server served), so there is probably nothing the human end user of the website can do to fix the problem, so we also have a reasonable argument for making the response a 500 internal server error, with the interpretation that the problem is something wrong with the server, but the "something" may have nothing to do with this particular call, because the original problem originated elsewhere in the code base (either in the call that built a bad list, or in a different call that returned a webpage that could not properly interact with the rest of the ecosystem).
Is there any standard that can be applied to this case? All of the documentation that I have found deals with the more clear cut cases, e.g. the caller is another server who provided a mangled request, or a human user submitted a form missing some fields, in which case the appropriate response code is much clearer to identify.
If the body of your request was missing some property, it is a client error and should be in the 4xx range of errors. 400 works for this, but 422 is probably slightly better.
As you mention, it's possible for this problem to occur as a side-effect of a different server-side error. However, the way HTTP generally works is that status codes are only relevant to the request you are actually making, not as a series of events that may have led to that request having been made.