格式良好但由于系统状态而无效的数据的正确状态代码

Question

我有一个系统，用户主要是用整数ID表示的。我有一个资源；让我们称它为X。X与两个用户相关联:一个创建X，另一个在创建者完成时批准X。X的审批人在通过POST提交时由创建者选择(或者稍后可以编辑)，请求通过用户ID标识审批者。还有一个额外的限制:审批人和创建者是配对的。只有当创建者被分配给他们时，审批者才能批准X。

因此，对于请求中批准者的用户ID，我有几个可能的失败案例：

1. 格式错误的ID (非整数)
2. 审批人ID是整数，但不存在具有该ID的用户。
3. 审批人ID是一个现有用户，但该用户不具有审批人角色。
4. 审批人ID是现有的审批人，但审批者没有分配给创建者。

显然，在第1种情况下，400是正确的状态代码，但它似乎不是2-4的正确状态代码。400指定格式错误的请求，但2-4是现有数据的问题，而不是解析请求的问题。我考虑了409，但这似乎是资源本身的问题。这是与资源X相关的额外资源的问题。我还考虑了406，但这似乎是为了以未知的格式提供内容(比如只有JSON被接受时的XML )。

那么，什么样的状态代码是合适的，以表明客户端提供了格式良好但糟糕的数据？

Answer 1

请注意，为了使客户了解清楚，您将始终包括对错误的解释，因此带有适当消息的稍微不准确的代码肯定会有帮助。

尽管如此，我将使用404 (未找到)作为1和2。整数或非整数，一个具有该ID的资源不存在。

3和4似乎都局限于我们的应用程序，所以我将使用400。403可用于3，但这可能意味着身份验证问题。

Answer 2

我同意“Will for 1&2-404”。

3和4，我会和409一起去。由于在一般情况下(您说审批者可以稍后更改)，在以下两种情况之间没有真正的区别(我可以看到)：

• 审批人ID是一个现有用户，但该用户不具有审批人角色。

和

• 审批人ID是一个现有的用户，5秒前他们是审批人，但现在不是这样了。

所以感觉就像编辑冲突一样。