HTTP幂等性

了解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中具有重要地位。

為什麼需要幂等性呢？我們先從一個例子說起，假設有一個從賬戶取錢的遠端API（可以是HTTP的，也可以不是），我們暫時用類函數的方式記為：

withdraw的語義是從account_id對應的賬戶中扣除amount數額的錢；如果扣除成功則傳回true，賬戶餘額減少amount；如果扣除失敗則傳回false，賬戶餘額不變。值得注意的是：和本地環境相比，我們不能輕易假設分布式環境的可靠性。一種典型的情況是withdraw請求已經被伺服器端正确處理，但伺服器端的傳回結果由于網絡等原因被掉丢了，導緻用戶端無法得知處理結果。如果是在網頁上，一些不恰當的設計可能會使使用者認為上一次操作失敗了，然後重新整理頁面，這就導緻了withdraw被調用兩次，賬戶也被多扣了一次錢。如圖1所示：

圖1

這個問題的解決方案一是采用分布式事務，通過引入支援分布式事務的中間件來保證withdraw功能的事務性。分布式事務的優點是對于調用者很簡單，複雜性都交給了中間件來管理。缺點則是一方面架構太重量級，容易被綁在特定的中間件上，不利于異構系統的內建；另一方面分布式事務雖然能保證事務的ACID性質，而但卻無法×××能和可用性的保證。

另一種更輕量級的解決方案是幂等設計。我們可以通過一些技巧把withdraw變成幂等的，比如：

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是幂等的，是以任何一步由于網絡等原因失敗或逾時，用戶端都可以重試，直到獲得結果。如圖2所示：

圖2

和分布式事務相比，幂等設計的優勢在于它的輕量級，容易适應異構環境，以及性能和可用性方面。在某些性能要求比較高的應用，幂等設計往往是唯一的選擇。

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表示更新資源”；而實際上，二者均可用于建立資源，更為本質的差别是在幂等性方面。在HTTP規範中對POST和PUT是這樣定義的：

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line ...... If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header. The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

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上進一步了解。