因此,HTTP规范指出HTTP PUT和DELETE应该是幂等的。这意味着,对具有相同正文的相同URL的多个PUT请求不应在服务器上产生其他副作用。多个HTTP DELETE相同,如果将2个或多个DELETE请求发送到同一URL,则第二个(或第三个等)请求不应返回错误,表明该资源已被删除。

但是,在处理完DELETE之后,如何对URI进行PUT请求呢?它应该返回404吗?

例如,考虑以下请求按此顺序执行:

  • POST/api/items-创建item资源,返回HTTP 201和URI/api/items/6
  • PUT/api/items/6-更新与item#6
  • 相关的数据
  • PUT/api/items/6-只要请求正文与先前的PUT
  • 相同,就没有副作用
  • DELETE/api/items/6-删除item#6并返回HTTP 202
  • DELETE/api/items/6-没有副作用,并且还返回HTTP 202
  • GET/api/items/6-现在将返回404
  • 输入/api/items/6-这里应该发生什么? 404? 409?还有别的吗

  • 因此,PUT是否应该与get和return 404一致,或者像@CodeCaster所建议的那样,409是否更合适?

    最佳答案



    和:



    因此,定义“适当的”就是查看400系列,这表明存在客户端错误。首先,我将消除不相关的内容:

  • 400错误的请求:由于格式错误,服务器无法理解该请求
    句法。
  • 401未经授权的:该请求需要用户身份验证。
  • 402需要付款:此代码保留供将来使用。
  • 406 Not Acceptable :请求所标识的资源 Not Acceptable
    根据请求中发送的接受 header 。
  • 407必需的代理身份验证:此代码表示...
    客户端必须首先使用代理进行身份验证。
  • 408请求超时:客户端在服务器准备等待之前未产生请求。
  • 411所需长度:服务器拒绝接受没有定义Content-
    长度。

  • 那么,我们可以使用哪些呢?



    实际上,此描述非常合适,尽管它通常在与权限相关的上下文中使用(例如:您可能不会...)。



    这也是,尤其是最后一行。



    没有有效的方法可以响应,因为我们目前不希望在此资源上执行任何方法,因此我们无法返回405。



    但这假设URI上已经有一个资源(怎么可能没有冲突?)。



    这一点也很有意义。

    我现在已经编辑过几次该帖子,当它声称“使用410或404”时被接受,但是现在我认为403也可能适用,因为RFC并未指出403必须与权限相关(但似乎可以通过流行的网络服务器以这种方式实现)。我想我已经消除了所有其他400码,但是可以随意发表评论(在您低票之前)。

    10-07 15:49
    查看更多