无法删除最后一个联系人 - 什么 Http 状态代码？

Question

我目前正在构建一个 Web API，并且有一个特定的场景，我无法确定哪个 HTTP 状态代码最适合返回。

情景

我有一个“客户”资源，它拥有一组联系人资源。

不变的是客户必须始终至少有一个联系人。因此，如果请求删除联系人并且此联系人是给定客户端的最后一个联系人，我需要返回一个适当的 HTTP 响应，指示该请求无法完成，因为您“无法删除最后一个联系人”。

我的感觉是这应该属于“4xx客户端错误”的范畴

我考虑过以下状态代码：

400 Bad Request - 我已经排除了这一点，因为它专门针对服务器无法理解的格式错误的请求。

405 Method Not Allowed - 起初这似乎很合适，但我认为 405 表示永远不应该允许这种方法，但上述情况只是暂时的。想法？

409 冲突 - 我一直倾向于这样做，但是为此代码给出的常见示例通常是并发异常/编辑冲突。

有人对我在这种情况下应该如何应对有任何指导吗？

Answer 1

关键是查看客户端的期望并在使用特定状态码时进行缓存。

这里有一些有用的 RFC2616 块：

10.4.1。 400 错误请求

由于语法错误，服务器无法理解该请求。客户端不应该不加修改地重复请求。

这表明请求本身是完全错误的——无论是语法还是协议。您的具体情况确实是应用程序协议错误，因此这可能确实是合适的。

10.4.6。 405 方法不允许

Request-URI 标识的资源不允许使用Request-Line 中指定的方法。响应必须包含一个 Allow 标头，其中包含所请求资源的有效方法列表。

这是一个临时状态代码。如果DELETE 专门指联系资源本身（例如DELETE /contacts/D9DF5176-EEE4-4C70-8DA7-BA57B82027A8），那么这可能是最合适的状态代码。但是，如果 DELETE 位于不同的资源或带有查询的资源（例如，DELETE /contacts?index=12）上，那么我不会返回 405。再说一次，我通常避免使用 DELETE 与任何类似的查询。

10.4.10。 409 冲突

由于与资源的当前状态冲突，请求无法完成。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。响应正文应该包含足够的信息让用户识别冲突的来源。理想情况下，响应实体将包含足够的信息供用户或用户代理解决问题；但是，这可能是不可能的，也不是必需的。

乍一看，这似乎是最合适的状态。在你的情况下，我可能更喜欢 400。 409 将清楚地表明与资源存在冲突，但除了完全改变资源（即首先添加联系人）之外，请求者实际上无法做任何事情来改变结果。大多数 409 响应是乐观并发失败，例如尝试修改自检索后已修改的资源。例如，查看concurrency failures returned by AtomServer built over Apache Adbera。

所有这些。我可能会使用400 Cannot Delete Last Contact 之类的东西作为响应线。请记住，您可以更改与状态代码相关的短语。现在是做这种事情的好时机。