我目前正在构建一个 Web API，并且有一个特定的场景，我无法确定哪个 HTTP 状态代码最适合返回。
情景
我有一个“客户”资源，它拥有一组联系人资源。
不变的是客户必须始终至少有一个联系人。因此，如果请求删除联系人并且此联系人是给定客户端的最后一个联系人，我需要返回一个适当的 HTTP 响应，指示该请求无法完成，因为您“无法删除最后一个联系人”。
我的感觉是这应该属于“4xx 客户端错误”的类别
我考虑了以下状态代码：
400 Bad Request - 我已经排除了这一点，因为它专门针对服务器无法理解的格式错误的请求。
405 Method Not Allowed - 起初这似乎很合适，但我认为 405 表示永远不应该允许这种方法，但是上述情况只是暂时的。想法？
409 Conflict - 我一直倾向于这个，但是这个代码给出的常见示例通常是并发异常/编辑冲突。
有人对我在这种情况下应该如何应对有任何指导吗？
关键是在使用特定状态代码时查看客户端和缓存的期望。
以下是一些有用的 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 响应是乐观并发失败，例如尝试修改自检索后已修改的资源。例如，查看基于Apache Adbera 构建的 AtomServer 返回的并发故障。
因此，所有这些。我可能会使用类似的东西400 Cannot Delete Last Contact作为响应线。请记住，您可以更改与状态代码相关的短语。现在是做这种事情的好时机。