REST：删除和业务逻辑条件答案

【问题标题】：REST: DELETE and Business Logic conditionsREST：删除和业务逻辑条件
【发布时间】：2011-12-30 22:51:53
【问题描述】：

在 REST API 中实施业务逻辑时，实际/传统做法是什么？使用哪些 HTTP 状态代码？

例如，假设我有一个 Player 实体和一个 Team 实体。一个团队可以有任意数量的玩家。

假设我的业务逻辑（当前）阻止一个团队被删除，直到所有玩家都被明确地从团队中删除。

如果你执行一个

DELETE http://api.foo.com/teams/15

并且它仍然有与之关联的玩家，您会返回 HTTP 409（冲突）还是 HTTP 412（前提条件失败）？ 412 似乎更合乎逻辑，因为我更喜欢使用 409 来表示乐观锁定条件。

或者也许 - 是否应该在 REST API 中强制执行该业务逻辑条件？也就是说，如果有人执行

DELETE http://api.foo.com/teams/15

不应该只是删除所有玩家然后自动删除团队吗？允许 DELETE 执行是否更传统，因为 REST API 可以被视为比 UI 界面更“低级”或更“原始”？

最后，资源 URI 中的查询参数如何：

DELETE http://api.foo.com/teams/15?force=true

这表示，“是的，我知道对于仍在团队中的球员来说这是不允许的，但无论如何都要这样做”。

这里的想法是，删除团队可能是一项具有重大影响的重量级操作，并且您只有在最终用户确定他们愿意的情况下才愿意这样做。

换句话说，你做了多少手把手（使用“你确定吗？”错误代码）还是直接执行而不做任何检查？我不太确定这是否应该仅在 UI 或 REST API 或两者中强制执行。今天大多数人是如何解决这个问题的？

【问题讨论】：

标签： rest business-logic http-status-codes confirmation

【解决方案1】：

出于业务原因，客户试图做一些不是有效请求的事情。因此，我会使用 400。如果您想传达更多详细信息，请使用 ReasonPhrase/entity 正文。

【讨论】：

【解决方案2】：

412 在这种情况下是不正确的，因为这是基于请求标头字段的评估（请参阅 this question 了解何时使用 HTTP 412）。这里正确的状态码是 403 Forbidden——即请求被理解，但拒绝这样做，授权也无济于事。您可以在响应正文中向客户端提供更多详细信息。

至于是否应该实现业务逻辑，这完全取决于您。您甚至可以选择基于 ACL 实施这种检查——例如，某些用户只有在所有球员都被删除后才能删除球队，而管理员无论如何都可以删除球队。一个非管理员用户向一个有球员的球队发出 DELETE 请求现在应该返回 401 Unauthorized（即针对这些凭据的操作被拒绝）。管理员用户将获得 200。

编辑：更多信息，一如既往，RFC 2616。

【讨论】：

【解决方案3】：

我在 Lotus Notes 上托管 REST 服务的案例中，如果我们需要从 Lotus Notes 中删除任何条目，我们强制设置“确认/强制”参数为真，以确保调用者（UI/REST 客户端）知道删除。如果您的服务是 REST 服务，我认为在 UI 级别还不够，我们还需要在 REST URL 中具有相同的约束。

我没有遇到你提到的任何情况（删除团队应该删除玩家），但在这种特殊情况下我更倾向于 412 代码。

【讨论】：