如果DELETE不可能，则为REST HTTP状态代码

Question

当资源上无法进行DELETE （但不涉及用户权限）时，我的问题是关于HTTP状态代码的非常通用的问题。

我们在一种资源上有一个RESTful API。

DELETE方法在资源上被授权，但在某些情况下无法删除资源（如果有数据绑定到此资源）。

在这种情况下，返回客户端的正确HTTP状态代码是什么？

以下是我收集的一些可能性以及为什么它在我的案例中似乎不合适：

• 403 （ 禁止 ）：似乎主要与用户的权利有关。
• 405 （ 不允许的方法 ）：似乎API不是为这种类型的资源响应此方法而设计的。
• 409 （ 冲突 ）：似乎合适，但客户应该有可能解决与API的冲突，但这不是这种情况。

更新：无法通过REST API更改阻止资源被删除的数据绑定。 但是，资源可以通过其他方式“释放”，因为数据所来自的数据库也可以被其他应用程序访问，这些应用程序可能会更改资源的状态（DB中的SQL DELETE总是可以这样做）。

Answer 1

我认为409是最合适的，因为它在RFC中的措辞：

409（冲突）状态代码表示由于与目标资源的当前状态冲突而无法完成请求。 此代码用于用户可能能够解决冲突并重新提交请求的情况。 服务器应该生成一个有效载荷，其中包含足够的信息供用户识别冲突源。

（强调我的）

根据我对问题描述的理解，不允许DELETE的原因与目标资源的当前状态完全冲突 。 如RFC中所示，响应有效载荷可以指示原因，并且可选地 ，用户可能能够解析它。 我没有看到规范中的任何内容使409不合适只是因为API不提供冲突解决的可能性。

Answer 2

如果客户端无法解决冲突并稍后删除请求，那么409 Conflict响应肯定是错误的。 也就是说，除非资源有状态跟踪是否可以删除，否则409 Conflict不适合。

403 Forbidden并不一定意味着没有授权：

但是，出于与凭证无关的原因，可能会禁止请求。
- RFC 7231

但这意味着通常存在。 您可以使用此代码，但可能会引起一些混淆。 如果方法实际上也需要授权，那将特别棘手 - 您需要在响应中使用代码或其他内容来指示失败是与授权相关还是资源是不可删除的。

我认为405 Method Not Allowed是正确的方法。

405（方法不允许）状态代码表示请求行中接收的方法由源服务器知道但目标资源不支持。
- RFC 7231

此资源不支持DELETE方法。 这听起来就像你所描述的那样。 HTTP规范实际上没有一种资源的概念 - 只是一种资源。 碰巧人们将相同端点下的个人资源分组以获得理智，但这对开发人员和用户来说只是一种便利。 就HTTP规范而言， /widgets/12和/widgets/15和/widgets/3453是三种不同的资源。 同一个对象代表服务器上所有这三个资源的事实完全无关紧要。 我认为这是你想到的“类型”，但对于HTTP来说这只是一个实现细节。