HTTP冪等性
基於HTTP協議的Web API是時下最爲流行的一種分佈式服務提供方式。無論是在大型互聯網應用還是企業級架構中，我們都見到了越來越多的SOA或RESTful的Web API。爲什麼Web API如此流行呢？我認爲很大程度上應歸功於簡單有效的HTTP協議。HTTP協議是一種分佈式的面向資源的網絡應用層協議，無論是服務器端提供Web服務，還是客戶端消費Web服務都非常簡單。再加上瀏覽器、Javascript、AJAX、JSON以及HTML5等技術和工具的發展，互聯網應用架構設計表現出了從傳統的PHP、JSP、ASP.NET等服務器端動態網頁向Web API + RIA（富互聯網應用）過渡的趨勢。Web API專注於提供業務服務，RIA專注於用戶界面和交互設計，從此兩個領域的分工更加明晰。在這種趨勢下，Web API設計將成爲服務器端程序員的必修課。然而，正如簡單的Java語言並不意味着高質量的Java程序，簡單的HTTP協議也不意味着高質量的Web API。要想設計出高質量的Web API，還需要深入理解分佈式系統及HTTP協議的特性。
冪等性定義
本文所要探討的正是HTTP協議涉及到的一種重要性質：冪等性(Idempotence)。在HTTP/1.1規範中冪等性的定義是：
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.
從定義上看，HTTP方法的冪等性是指一次和多次請求某一個資源應該具有同樣的副作用。冪等性屬於語義範疇，正如編譯器只能幫助檢查語法錯誤一樣，HTTP規範也沒有辦法通過消息格式等語法手段來定義它，這可能是它不太受到重視的原因之一。但實際上，冪等性是分佈式系統設計中十分重要的概念，而HTTP的分佈式本質也決定了它在HTTP中具有重要地位。
分佈式事務 vs 冪等設計
爲什麼需要冪等性呢？我們先從一個例子說起，假設有一個從賬戶取錢的遠程API（可以是HTTP的，也可以不是），我們暫時用類函數的方式記爲：
bool withdraw(account_id, amount)
withdraw的語義是從account_id對應的賬戶中扣除amount數額的錢；如果扣除成功則返回true，賬戶餘額減少amount；如果扣除失敗則返回false，賬戶餘額不變。值得注意的是：和本地環境相比，我們不能輕易假設分佈式環境的可靠性。一種典型的情況是withdraw請求已經被服務器端正確處理，但服務器端的返回結果由於網絡等原因被掉丟了，導致客戶端無法得知處理結果。如果是在網頁上，一些不恰當的設計可能會使用戶認爲上一次操作失敗了，然後刷新頁面，這就導致了withdraw被調用兩次，賬戶也被多扣了一次錢。如圖1所示：
non-idempotent
這個問題的解決方案一是採用分佈式事務，通過引入支持分佈式事務的中間件來保證withdraw功能的事務性。分佈式事務的優點是對於調用者很簡單，複雜性都交給了中間件來管理。缺點則是一方面架構太重量級，容易被綁在特定的中間件上，不利於異構系統的集成；另一方面分佈式事務雖然能保證事務的ACID性質，而但卻無法提供性能和可用性的保證。
另一種更輕量級的解決方案是冪等設計。我們可以通過一些技巧把withdraw變成冪等的，比如：
int create_ticket()
bool idempotent_withdraw(ticket_id, account_id, amount)
create_ticket的語義是獲取一個服務器端生成的唯一的處理號ticket_id，它將用於標識後續的操作。idempotent_withdraw和withdraw的區別在於關聯了一個ticket_id，一個ticket_id表示的操作至多隻會被處理一次，每次調用都將返回第一次調用時的處理結果。這樣，idempotent_withdraw就符合冪等性了，客戶端就可以放心地多次調用。
基於冪等性的解決方案中一個完整的取錢流程被分解成了兩個步驟：1.調用create_ticket()獲取ticket_id；2.調用idempotent_withdraw(ticket_id, account_id, amount)。雖然create_ticket不是冪等的，但在這種設計下，它對系統狀態的影響可以忽略，加上idempotent_withdraw是冪等的，所以任何一步由於網絡等原因失敗或超時，客戶端都可以重試，直到獲得結果。
idempotent
和分佈式事務相比，冪等設計的優勢在於它的輕量級，容易適應異構環境，以及性能和可用性方面。在某些性能要求比較高的應用，冪等設計往往是唯一的選擇。
HTTP的冪等性
HTTP協議本身是一種面向資源的應用層協議，但對HTTP協議的使用實際上存在着兩種不同的方式：一種是RESTful的，它把HTTP當成應用層協議，比較忠實地遵守了HTTP協議的各種規定；另一種是SOA的，它並沒有完全把HTTP當成應用層協議，而是把HTTP協議作爲了傳輸層協議，然後在HTTP之上建立了自己的應用層協議。本文所討論的HTTP冪等性主要針對RESTful風格的，不過正如上一節所看到的那樣，冪等性並不屬於特定的協議，它是分佈式系統的一種特性；所以，不論是SOA還是RESTful的Web API設計都應該考慮冪等性。下面將介紹HTTP GET、DELETE、PUT、POST四種主要方法的語義和冪等性。
HTTP GET方法用於獲取資源，不應有副作用，所以是冪等的。比如：GET http://www.bank.com/account/123456，不會改變資源的狀態，不論調用一次還是N次都沒有副作用。請注意，這裏強調的是一次和N次具有相同的副作用，而不是每次GET的結果相同。GET http://www.news.com/latest-news這個HTTP請求可能會每次得到不同的結果，但它本身並沒有產生任何副作用，因而是滿足冪等性的。
HTTP DELETE方法用於刪除資源，有副作用，但它應該滿足冪等性。比如：DELETE http://www.forum.com/article/4231，調用一次和N次對系統產生的副作用是相同的，即刪掉id爲4231的帖子；因此，調用者可以多次調用或刷新頁面而不必擔心引起錯誤。
比較容易混淆的是HTTP POST和PUT。POST和PUT的區別容易被簡單地誤認爲“POST表示創建資源，PUT表示更新資源”；而實際上，二者均可用於創建資源，更爲本質的差別是在冪等性方面。
POST所對應的URI並非創建的資源本身，而是資源的接收者。比如：POST http://www.forum.com/articles的語義是在http://www.forum.com/articles下創建一篇帖子，HTTP響應中應包含帖子的創建狀態以及帖子的URI。兩次相同的POST請求會在服務器端創建兩份資源，它們具有不同的URI；所以，POST方法不具備冪等性。而PUT所對應的URI是要創建或更新的資源本身。比如：PUT http://www.forum/articles/4231的語義是創建或更新ID爲4231的帖子。對同一URI進行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有冪等性。
在介紹了幾種操作的語義和冪等性之後，我們來看看如何通過Web API的形式實現前面所提到的取款功能。很簡單，用POST /tickets來實現create_ticket；用PUT /accounts/account_id/ticket_id?amount=xxx來實現idempotent_withdraw。值得注意的是嚴格來講amount參數不應該作爲URI的一部分，真正的URI應該是/accounts/account_id/ticket_id，而amount應該放在請求的body中。這種模式可以應用於很多場合，比如：論壇網站中防止意外的重複發帖。
總結
上面簡單介紹了冪等性的概念，用冪等設計取代分佈式事務的方法，以及HTTP主要方法的語義和冪等性特徵。其實，如果要追根溯源，冪等性是數學中的一個概念，表達的是N次變換與1次變換的結果相同，有興趣的讀者可以從Wikipedia上進一步瞭解。