摘要： PUT是idempotent的方法，而POST不是。
有的觀點認為，應該用POST來建立一個資源，用PUT來更新一個資源；有的觀點認為，應該用PUT來建立一個資源，用POST來更新一個資源；還有的觀點認為可以用PUT和POST中任何一個來做建立或者更新一個資源。這些觀點都只看到了風格，爭論起來也只是爭論哪種風格更好，其實，用PUT還是POST，不是看這是建立還是更新資源的動作，這不是風格的問題，而是語義的問題。
在HTTP中，PUT被定義為idempotent的方法，POST則不是，這是一個很重要的區別。
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.
上面的話就是說，如果一個方法重複執行多次，產生的效果是一樣的，那就是idempotent的。
舉一個簡單的例子，假如有一個部落格系統提供一個Web API，模式是這樣http://superblogging/blogs/post/{blog-name}，很簡單，將{blog-name}替換為我們的blog名字，往這個URI傳送一個HTTP PUT或者POST請求，HTTP的body部分就是博文，這是一個很簡單的REST API例子。我們應該用PUT方法還是POST方法？取決於這個REST服務的行為是否是idempotent的，假如我們傳送兩個http://superblogging/blogs/post/Sample請求，伺服器端是什麼樣的行為？如果產生了兩個部落格帖子，那就說明這個服務不是idempotent的，因為多次使用產生了副作用了嘛；如果後一個請求把第一個請求覆蓋掉了，那這個服務就是idempotent的。前一種情況，應該使用POST方法，後一種情況，應該使用PUT方法。
也許你會覺得這個兩個方法的差別沒什麼大不了的，用錯了也不會有什麼問題，但是你的服務一放到internet上，如果不遵從HTTP協議的規範，就可能給自己帶來麻煩。比如，沒準Google Crawler也會訪問你的服務，如果讓一個不是indempotent的服務可以用indempotent的方法訪問，那麼你伺服器的狀態可能就會被Crawler修改，這是不應該發生的。
國外文章摘錄，具體忘記名稱作者和url了~