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

Question

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

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

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

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

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

• 403 （禁止）：似乎主要与用户的权利有关。
• 405 （方法不允许）：似乎API并非旨在针对此类资源响应此方法。
• 409 （冲突）：似乎合适，但客户应该有可能解决与API的冲突，但这不是这种情况。< / LI>

更新：无法通过REST API更改阻止资源删除的数据绑定。然而，资源可以被释放＆＃34;通过其他方式，数据来自的数据库也可以被其他可能改变资源状态的应用程序访问（DB中的SQL DELETE总是可以这样做）。

Answer 1

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

  

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

（强调我的）

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

Answer 2

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

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

  

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

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

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

  

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

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