2

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

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

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

400 显然是案例 1 的正确状态码，但它似乎不是 2-4 的正确状态码。400 指定格式错误的请求，但 2-4 是特定于现有数据的问题，而不是解析请求的问题。我考虑过 409，但这似乎是资源本身的问题。这是与资源 X 相关的附加资源的问题。我也考虑过 406，但这似乎是为了提供未知格式的内容（如仅接受 JSON 时的 XML）。

那么什么状态码适合表明客户端提供了格式良好但错误的数据？

4

2 回答 2

2

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

话虽如此，我会为 1 和 2 使用 404（未找到）。无论是否为整数，具有该 ID 的资源都不存在。

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

于 2013-10-28T07:40:22.323 回答
2

我同意@Will 的 1 和 2 - 404。

对于 3 和 4，我会选择 409。因为在一般情况下（您说可以稍后更改批准者），以下之间没有真正的区别（我可以看到）：

  • 审批者 ID 是现有用户，但该用户没有审批者角色。

和

  • 批准人 ID 是现有用户，5 秒前他们是批准人，但现在不再是这种情况

所以感觉和编辑冲突一样。

于 2013-10-28T07:45:15.140 回答