http 冪等方法，是指無論呼叫多少次都不會有不同結果的 http 方法。不管你呼叫一次，還是呼叫一百次，一千次，結果都是相同的。
http get 方法，用於獲取資源，不管呼叫多少次介面，結果都不會改變，所以是冪等的。
get /tickets # 獲取ticket列表
get /tickets/12 # 檢視某個具體的ticket
值得注意的是，冪等性指的是作用於結果而非資源本身。怎麼理解呢？例如，這個 http get 方法可能會每次得到不同的返回內容，但並不影響資源。
可能你會問有這種情況麼？當然有咯。例如，我們有乙個介面獲取當前時間，我們就應該設計成
get /service_time # 獲取伺服器當前時間http post 方法是乙個非冪等方法，因為呼叫多次，都將產生新的資源。
post /tickets # 新建乙個ticketput /tickets/12 # 更新ticket 12http patch 方法是非冪等的。http post 方法和 http put 方法可能比較好理解，但是 http patch 方法只是更新部分資源，怎麼是非冪等的呢?
因為，patch 提供的實體則需要根據程式或其它協議的定義，解析後在伺服器上執行，以此來修改伺服器上的資源。換句話說，patch 請求是會執行某個程式的，如果重複提交，程式可能執行多次，對伺服器上的資源就可能造成額外的影響，這就可以解釋它為什麼是非冪等的了。
patch /tickets/12 # 更新ticket 12http delete 方法用於刪除資源，會將資源刪除。
delete /tickets/12 # 刪除ticekt 12也許，你會想起乙個面試題。http 請求的 get 與 post 方式有什麼區別？ 你可能會回答到：get 方式通過 url 提交資料，資料在 url 中可以看到；post 方式，資料放置在 html header 內提交。但是，我們現在從 restful 的資源角度來看待問題，http get 方法是冪等的，所以它適合作為查詢操作，http post 方法是非冪等的，所以用來表示新增操作。
但是，也有例外，我們有的時候可能需要把查詢方法改造成 http post 方法。比如，超長（1k）的 get url 使用 post 方法來替代，因為 get 受到 url 長度的限制。雖然，它不符合冪等性，但是它是一種折中的方案。
對於 http post 方法和 http put 方法，我們一般的理解是 post 表示建立資源，put 表示更新資源。當然，這個是正確的理解。
但是，實際上，兩個方法都用於建立資源，更為本質的差別是在冪等性。http post 方法是非冪等，所以用來表示建立資源，http put 方法是冪等的，因此表示更新資源更加貼切。
此時，你看會有另外乙個問題。http put 方法和 http patch 方法，都是用來表述更新資源，它們之間有什麼區別呢？我們一般的理解是 put 表示更新全部資源，patch 表示更新部分資源。首先，這個是我們遵守的第一準則。根據上面的描述，patch 方法是非冪等的，因此我們在設計我們服務端的 restful api 的時候，也需要考慮。如果，我們想要明確的告訴呼叫者我們的資源是冪等的，我的設計更傾向於使用 http put 方法。
什麼是冪等
簡單來說 重複呼叫多次產生的業務結果與呼叫一次產生的業務結果相同 在分布式架構中，我們呼叫乙個遠端服務去完成乙個操作，除了成功和失敗以外，還有未知狀態，那麼針對這個未知狀態，我們會採取一些重試的行為 或者在訊息中介軟體的使用場景中，消費者可能會重複收到訊息。對於這兩種情況，消費端或者服務端需要採取一...
什麼是冪等性解決方案
今天看到一篇講冪等的文章，想起來上次面試的時候有問過，記錄一下，加深印象。首先說一下冪等的概念，官方一點的說法是 在程式設計中乙個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。其實可以簡單理解為多次操作和一次操作的結果是一樣的。一般情況下介面正常呼叫的時候返回資訊不會重複提交，但...
什麼是冪等，什麼情況下需要冪等，如何實現冪等
在微服務架構下，我們在完成乙個訂單流程時經常遇到下面的場景 乙個訂單建立介面，第一次呼叫超時了，然後呼叫方重試了一次 在訂單建立時，我們需要去扣減庫存，這時介面發生了超時，呼叫方重試了一次 當這筆訂單開始支付，在支付請求發出之後，在服務端發生了扣錢操作，介面響應超時了，呼叫方重試了一次 乙個訂單狀態...