从CouchDB documentation报价：是否应该阻止HTTP POST？
建议您避免POST可能的情况下，因为代理服务器和其他网络中介有时会重新发送POST请求，这可能会导致重复的文档创建。
据我的理解，这不应该发生在协议层面（一个困惑的用户配备双击是一个完全不同的故事）。那么最好的行动方案是什么？
我们是否应该尽量避免POST请求并用PUT替换它们？我不喜欢那个，因为它们表达了不同的含义。
我们是否应该通过唯一ID来预测并保护请求，以避免意外重复？我也不喜欢这样做：它使代码复杂化，并防止可能需要多个相同的帖子的情况。
如果我们真的尽力避免POST请求 和PUT取代他们？ I 不喜欢那样，因为它们表达了不同的含义。
对于文档创建（如您在文档中提到的那样），这正是正确的含义。对于文档修改，偶尔的重新发送请求不是问题。
在我的WebMaster时代，我一定非常幸运，从未见过重复的POST请求。
TCP/IP发送编号的消息，我不知道为什么任何Web服务器不会丢弃重复。
这是重复邮政事情真的一个问题？
只能使用**真**代理，因为它用于常规网站上的金融交易。 – 2010-05-18 10:11:33
当请求是idempotent并且确实会改变服务器状态（它不应该在每次执行时改变服务器状态，在文档创建中这意味着文档应该只创建一次）。
当请求是非幂等性时，POST是合适的。这意味着每次发送请求时都会改变服务器状态。对于更新或删除这应该没有关系。
当然，由于Web浏览器的支持，只有GET和POST请求才被采用，因为POST会执行所有的PUT操作（它不是为幂等请求设计的）。
我认为你已经倒过来了：POST对于幂等变化是很好的（试图再次删除某些东西可能会产生错误，但不会损坏数据）并且对于非幂等变量不好（例如，意外创建文档两次） 。 – 2010-05-18 09:58:07
你确定吗？ PUT被列为幂等，POST是非幂等的。删除可能是一个不好的例子，因为这实际上应该由幂等DELETE方法完成。 – 2010-05-18 10:15:39
目前还不清楚这个文档是什么，但它肯定不是代理服务器重新发送POST，我从来没有见过它发生。 – bobince 2010-05-18 09:35:19