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

Question

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

情景

我有一个"客户端"资源,拥有一组联系人资源.

不变量是客户必须始终至少有一个联系人.因此,如果请求删除联系人并且此联系人是给定客户端的最后剩余联系人,我需要返回一个适当的HTTP响应,指示无法满足请求,因为您"无法删除最后一个联系人".

我觉得这应属于"4xx Client Error's"的范畴

我考虑过以下状态代码:

400错误请求 - 我已经排除了这一点,因为它特别针对服务器无法理解的格式错误的请求.

405方法不允许 - 首先这似乎合适,但我认为405表明绝不允许这种方法,但上述情况只是暂时的.思考？

409冲突 - 我一直倾向于此,但是为此代码提供的常见示例通常是并发异常/编辑冲突.

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

Answer 1

关键是要在使用特定状态代码时查看客户端和缓存的期望.

以下是一些有用的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.然后,我通常避免使用DELETE类似查询的任何内容.

10.4.10.409冲突

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

这看起来似乎是最合适的状态.在你的情况下,我可能更喜欢400.409将清楚地表明存在与资源的冲突但是实际上没有任何请求者可以做的事情可以改变结果而不是完全改变资源(即,首先添加联系人).409个响应中的大多数都是乐观并发失败,例如尝试修改自检索以来修改过的资源.例如,查看由Apache Adbera构建的AtomServer返回的并发故障.

所有这些都是如此.我可能会使用类似400 Cannot Delete Last Contact响应行的东西.请记住,您可以更改与状态代码关联的短语.这是做这种事情的好时机.