REST風格中POST與PUT差別

 

REST（Representational State Transfer）是網路服務介面的一種風格，並不是一個標準，就web service而言，REST要比SOAP（SOAP是標準，不是風格）輕量得多，容易得多。我記得我最初開始接觸web service的時候，所有的材料上來就是一大堆的名詞，SOAP, WSDL,看得頭都要大了，後來提出來的REST就容易理解得多，雖然目前SOAP在企業級的web service中還有一席之地，但是在公用的Internet上，不是REST的服務實在不好意思和人打招呼，我們經常可以看到評價某某服務是RESTful的，但是從來沒有聽說某某服務是SOAPful的。

微軟對REST的支援有點晚，自.NET3.5開始，WCF也可以提供RESTful介面。當然，REST不光限於web service，網頁服務也可以RESTful，微軟的ASP.NET MVC架構提供了直接的REST支援。

因為REST只是風格，不是標準，所以有的方面容易有誤解，比如說建立和更新某個URI代表的資源的時候，是用HTTP的PUT還是POST命令。REST常用的四種HTTP命令，GET、DELETE、PUT和POST，對於GET和DELETE，一個是擷取資源，一個是刪除資源，沒什麼異議，問題是PUT和POST，兩者都有更改指定URI的語義，那麼，究竟是用哪一個呢？

有的觀點認為，應該用POST來建立一個資源，用PUT來更新一個資源；有的觀點認為，應該用PUT來建立一個資源，用POST來更新一個資源；還有的觀點認為可以用PUT和POST中任何一個來做建立或者更新一個資源。這些觀點都只看到了風格，爭論起來也只是爭論哪種風格更好，其實，用PUT還是POST，不是看這是建立還是更新資源的動作，這不是風格的問題，而是語義的問題。

REST是一種風格，但是還是依賴於HTTP協議，在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修改，這是不應該發生的。