据我了解，除了为未知的端点返回404 Not Found外，REST API 在以下情况下还应该返回 404：
/users/{id}存在，但/users/123456不存在/search存在，但/search?user=123456如果用户不存在则返回404（我问了@987654321 @ 几年前）现在端点接受带有多个字段的 JSON 对象的用例怎么样，其中一个是不存在的用户的 ID：
POST /makeReservation HTTP/1.1
...
{
"userId": 123456,
...
}
这是否也应该返回 404，或者在这种情况下这是否被视为另一种错误（验证错误？）？
【问题讨论】：
标签： rest http http-status-code-404
据我了解
我想说你目前的理解比它应该的要复杂一些。
404 Not Found 表示：
404（未找到）状态码表示源服务器没有找到目标资源的当前表示或不愿意透露存在的表示。
如果“目标资源”不清楚，我们可以查看Request Line的规范。
request-line = 方法 SP 请求目标 SP HTTP 版本 CRLF
request-target 标识应用请求的目标资源，如Section 5.3 中所定义。
换句话说，404 表示“请求目标的拼写有问题”。
因此，当实际问题在请求正文中时，暗示请求目标存在问题是一种误导。
这种情况下您可能需要的错误代码是422 Unprocessable Entity
422 (Unprocessable Entity) 状态码表示服务器 理解请求实体的内容类型（因此 415（不支持的媒体类型）状态码不合适），并且 请求实体的语法是正确的（因此是 400 (Bad Request) 状态码不合适）但无法处理包含的 指示。例如，如果 XML 请求正文包含格式正确（即语法正确），但是 语义错误的 XML 指令。
IANA 的HTTP Status Code Registry 是一个很好的地方，当您确定应该有适合您的用例的标准化代码，但您无法猜测是哪个规范描述它时。
它是 WebDAV 的一部分，我不确定将它用于其他应用程序是否正确？
TL;DR：将 if 用于其他应用程序是正确的。
HTTP 规范定义了process，通过该process，可以将新代码添加到状态代码注册表中，并且WebDAV 代码已遵循该过程。因此我们可以确信 422 的含义不会被其他语义所取代（为了兼容性，状态码已停用——参见状态码306。）
WebDAV 规范中 422 的定义不是特定于 WebDAV 的。
此外，不了解 WebDAV 规范的客户端的行为在 RFC 7231
中进行了描述客户端必须理解任何状态代码的类别，如第一个数字所示，并将无法识别的状态代码视为等同于该类别的 x00 状态代码，但接收者不得缓存响应带有无法识别的状态代码。
您还可以查看 WebDAV 规范的appendix B。
（作为旁注，我认为您的担忧是合理的——WebDAV 方法很难在该上下文之外重用。）
【讨论】：
422，虽然经常在与 REST 相关的问题中提出建议，但它是 WebDAV 的一部分，我不确定将它用于其他应用程序有多正确？