REST：DELETE和业务逻辑条件

Question

在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中强制执行。今天大多数人如何解决这个问题？

Answer 1

客户试图做一些因商业原因不是有效请求的事情。因此，我会使用400.如果要传达其他详细信息，请使用ReasonPhrase /实体正文。

Answer 2

在这种情况下，

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

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

编辑：一如既往地在RFC 2616中提供更多信息。

Answer 3

我在莲花笔记上托管REST服务的情况下，如果我们需要从莲花笔记中删除任何条目，我们强制要求设置确认/强制＆＃39; true参数，只是为了确保调用者（UI / REST客户端）知道删除。如果您的服务是REST服务，我认为在UI级别上还不够，我们还需要在REST URL中使用相同的约束。

我还没有遇到过你提到过的任何场景（删除团队应该删除播放器），但在这种特殊情况下，我会更倾向于412代码。