我目前正在构建一个Web API并且有一个特定的场景，我无法确定哪个HTTP状态代码最适合返回。
情景
我有一个“客户”资源，它拥有一组联系人资源。
不变量是客户必须始终至少有一个联系人。因此，如果请求删除联系人并且此联系人是给定客户端的最后剩余联系人，我需要返回一个适当的HTTP响应，指示无法满足请求，因为您“无法删除最后一个联系人”。< / p>
我的感觉是这应属于“4xx客户端错误”的类别
我考虑了以下状态代码：
400错误请求 - 我已经排除了这一点，因为它特别针对服务器无法理解的格式错误的请求。
405方法不允许 - 首先这似乎合适，但我认为405表示绝不允许这种方法，但上述情况只是暂时的。想法？
409冲突 - 我一直倾向于此，但是此代码的常见示例通常是并发异常/编辑冲突。
有没有人对我在这种情况下应该如何回应有任何指导？
答案 0 :(得分：7)
关键是要在使用特定状态代码时查看客户端和缓存的期望。
以下是RFC2616的一些有用的内容：
10.4.1。 400错误请求
由于语法格式错误，服务器无法理解该请求。客户不应该在没有修改的情况下重复请求。
这表明请求本身完全错误 - 无论是语法还是协议。您的具体情况实际上是应用程序协议错误，因此这可能确实合适。
10.4.6。 405方法不允许
请求行中指定的方法不允许由Request-URI标识的资源。响应必须包含一个Allow头，其中包含所请求资源的有效方法列表。
这是一个瞬态状态代码。如果DELETE专门针对联系人资源本身（例如DELETE /contacts/D9DF5176-EEE4-4C70-8DA7-BA57B82027A8），那么这可能是最合适的状态代码。但是，如果DELETE位于不同的资源或具有查询的资源（例如DELETE /contacts?index=12），那么我将不会返回405.然后，我通常避免使用{{1任何类似于查询的东西。
10.4.10。 409冲突
由于与资源的当前状态发生冲突，无法完成请求。此代码仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许。响应主体应该包含足够的信息供用户识别冲突的来源。理想情况下，响应实体将包含足够的信息供用户或用户代理解决问题;但是，这可能是不可能的，也不是必需的。
这看起来似乎是最合适的状态。在你的情况下，我可能更喜欢400。 409将清楚地表明存在与资源的冲突但是实际上没有任何请求者可以做的事情可以改变结果而不是完全改变资源（即，首先添加联系人）。 409个响应中的大多数都是乐观并发失败，例如尝试修改自检索以来修改过的资源。例如，查看concurrency failures returned by AtomServer built over Apache Adbera。
所有这一切。我可能会使用DELETE之类的东西作为响应行。请记住，您可以更改与状态代码关联的短语。这是做这件事的好时机。