我目前正在构建一个Web API，并且有一个特定的场景，我无法确定最适合返回哪个HTTP状态代码。
场景
我有一个"客户"资源，它拥有一组联系人资源。
不变的是客户端必须始终至少有一个联系人。因此，如果请求删除联系人，而该联系人是给定客户端的最后一个剩余联系人，我需要返回一个适当的HTTP响应，指示该请求无法满足，因为您"无法删除最后一个联系人"。
我的感觉是这应该属于"4xx客户端错误"的类别
我考虑了以下状态代码：
400错误请求-我已经排除了这一可能性，因为这是专门针对服务器无法理解的格式错误的请求。
405方法不允许-起初这似乎很合适，但我认为405表示永远不应该允许这种方法，但上述情况只是暂时的。想法？
409冲突-我一直倾向于这样做，但为这段代码给出的常见示例通常是并发异常/编辑冲突。
有没有人对我在这种情况下应该如何应对有任何指导？
关键是在使用特定状态代码时查看客户端和缓存的期望值。
以下是RFC2616中一些有用的部分：
10.4.1.400错误请求
由于语法不正确，服务器无法理解该请求。未经修改，客户不应重复请求。
这表示请求本身在语法上或协议上完全错误。您的具体情况实际上是一个应用程序协议错误，因此这可能确实是合适的。
10.4.6.405方法不允许
请求行中指定的方法不允许用于由请求URI标识的资源。响应必须包括一个Allow标头，该标头包含所请求资源的有效方法列表。
这是一个瞬态状态代码。如果DELETE具体指的是联系人资源本身(例如DELETE /contacts/D9DF5176-EEE4-4C70-8DA7-BA57B82027A8)，那么这可能是最合适的状态码。然而，如果DELETE在不同的资源或具有查询的资源(例如，DELETE /contacts?index=12)上，则我不会返回405。再说一遍，我通常避免将DELETE用于任何类似查询的内容。
10.4.10.409冲突
由于与资源的当前状态冲突，无法完成请求。只有在期望用户能够解决冲突并重新提交请求的情况下，才允许使用此代码。响应主体应包含足够的信息，以便用户识别冲突的来源。理想情况下，响应实体将包括足够的信息供用户或用户代理来解决问题；然而，这可能是不可能的，也不是必须的。
乍一看，这似乎是最合适的状态。我可能更喜欢你的400英镑。409将清楚地表明与资源存在冲突，但除了完全改变资源(即，首先添加联系人)之外，请求者确实无法做任何事情来改变结果。409个响应中的大多数是乐观并发故障，例如试图修改自检索以来已修改的资源。例如，看看在ApacheAdbera上构建的AtomServer返回的并发故障。
所有这些都是如此。我可能会使用类似400 Cannot Delete Last Contact的东西作为响应行。请记住，您可以更改与状态代码关联的短语。这真是做这种事的好时机。