HTTP協議中PUT和POST使用區別

摘要： PUT是idempotent的方法，而POST不是。

• 原文：HTTP協議中PUT和POST使用區別
• 做者：Never-say-Never

有的觀點認爲，應該用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了~