你真的了解rest api嗎？我們知道，springcloud做微服務時，服務之間的呼叫，服務的暴露使用的就是restful api，現在可以考慮這麼一種情況，加入我們有訂單服務a，支付服務b，a向b服務傳送了一次請求，但由於網路，超時等的原因，a認為b該次服務失敗，於是a又發起了一次同樣的請求，那麼這次請求會不會有什麼不良影響呢？如果b又呼叫了其它服務呢？
這裡我們可以引出乙個概念：在rest api中，當傳送多個相同的請求與傳送單個請求具有相同的效果時，該rest api就可以稱為冪等。所以a傳送相同的請求呼叫b服務不會出現業務邏輯的偏差，這樣b服務就是冪等的。
如果你在設計api時遵循rest原則，則get，put，delete，head，options和trace http方法的自動冪等rest api。只有post api不是冪等的。
post 不是冪等的。
get，put，delete，head，options和trace是冪等。
why？
通常，當然不是絕對； 我們使用post api在伺服器上是為了建立新資源。所以，呼叫相同的post請求n次時，您將在伺服器上擁有n個新資源。因此，post不是冪等的。
get，head，options和trace方法永遠不會改變伺服器上的資源狀態。因為它們全部用來獲取資料。因此，呼叫多個請求將不會在伺服器上進行任何寫操作，所以get，head，options和trace是冪等的。
使用put，patch api來更新資源狀態。呼叫put api n次，則第乙個請求將更新資源; n-1請求將一次又一次地覆蓋相同的資源狀態 - 實際上不會改變任何東西。因此，put是冪等的。
呼叫n個相同的delete請求時，第乙個請求將刪除資源，響應將是200 (ok)或204 (no content)。其他n-1請求將返回404 (not found)。顯然，響應與第乙個請求不同，但伺服器端的任何資源都沒有狀態更改，因為原始資源已被刪除。因此，delete是冪等的。
這裡值得注意的是，delete可能有這樣一種設計：
delete/user/latest刪除最新的使用者，這樣的話呼叫n次將刪除n個使用者，delete同樣不是冪等的，所以該api可以考慮設計成post
通常，我們為了給所有服務都設計成冪等，有以下解決辦法：
非同步處理，利用訊息中介軟體，a向中介軟體中傳送乙個訊息，a服務直接返回成功，b服務非同步消費。
唯一id，每次請求都可帶上唯一id，a傳送請求時，b可以知道該請求是否已經傳送過，有則直接忽略。
從冪等概念談起，再結合http各method意義談了每個方法是否冪等。 最後引出解決辦法。
關注我，這裡只有乾貨！
什麼是服務的冪等？為什麼要實現冪等？
目錄 什麼是冪等？讀和寫請求都需要做冪等嗎？系統的哪部分需要做冪等？資料訪問層的增刪改查都需要做冪等處理嗎？資料庫的修改做冪等 age 的情況展開討論 分布式系統的id如何生成？系統中的重複操作，不管執行多少次，都產生一樣的效果，或返回一樣的結果。讀請求不需要做冪等 因為讀請求不會對資料發生改變 寫...
REST真的完全適合微服務架構嗎？
本文講的是rest真的完全適合微服務架構嗎，編者的話 作者根據自己的微服務經驗，提出rest並不是微服務的唯一通訊機制，從而介紹了微服務的幾種通訊機制，包括rest 管道以及基於非同步訊息傳遞。同時，作者提出了在不同的場景下可以使用不同的通訊機制。在我接觸微服務的這段時間，大部分關於如何安裝部署微服...
關於web服務的介面冪等性
絕大部分網路上對冪等性的解釋類似於 冪等性是指重複使用同樣的引數呼叫同一方法時總能獲得同樣的結果。比如對同一資源的get請求訪問結果都是一樣的。我認為這種解釋是非常錯誤的,冪等性強調的是外界通過介面對系統內部的影響,外界怎麼看系統和冪等性沒有關係.就上面這種解釋,system.getcpuload ...