**冪等（idempotent /a?’d?mp?t?nt/、idempotence）**是一個數(shù)學(xué)與計算機學(xué)概念，常見于抽象代數(shù)中。

在編程中.一個冪等操作的特點是其任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同。
冪等函數(shù)，或冪等方法，是指可以使用相同參數(shù)重復(fù)執(zhí)行，并能獲得相同結(jié)果的函數(shù)。這些函數(shù)不會影響系統(tǒng)狀態(tài)，也不用擔(dān)心重復(fù)執(zhí)行會對系統(tǒng)造成改變。
例如，“getUsername()和setTrue()”函數(shù)就是一個冪等函數(shù).更復(fù)雜的操作冪等保證是利用唯一交易號(流水號)實現(xiàn).。

HTTP中的冪等性

從定義上看，HTTP方法的冪等性是指一次和多次請求某一個資源應(yīng)該具有同樣的副作用。說白了就是，同一個請求，發(fā)送一次和發(fā)送N次效果是一樣的。

案例

常見的一個冪等性的案例就是從銀行賬戶中取錢：withdraw(account_id, amount)函數(shù)。如果扣除成功返回true，賬戶余額減少amount；如果扣除失敗則返回false，賬戶余額不變。

值得注意的是：和本地環(huán)境相比，我們不能輕易假設(shè)分布式環(huán)境的可靠性。
一種典型的情況是withdraw請求已經(jīng)被服務(wù)器端正確處理，但服務(wù)器端的返回結(jié)果由于網(wǎng)絡(luò)等原因被掉丟了，導(dǎo)致客戶端無法得知處理結(jié)果。如果是在網(wǎng)頁上，一些不恰當?shù)脑O(shè)計可能會使用戶認為上一次操作失敗了，然后刷新頁面，這就導(dǎo)致了withdraw被調(diào)用兩次，賬戶也被多扣了一次錢。

解決方案一是采用分布式事務(wù)，通過引入支持分布式事務(wù)的中間件來保證withdraw功能的事務(wù)性。分布式事務(wù)的優(yōu)點是對于調(diào)用者很簡單，復(fù)雜性都交給了中間件來管理。
缺點則是一方面架構(gòu)太重量級，容易被綁在特定的中間件上，不利于異構(gòu)系統(tǒng)的集成；另一方面分布式事務(wù)雖然能保證事務(wù)的ACID性質(zhì)，而但卻無法提供性能和可用性的保證。

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

int create_ticket() 
bool idempotent_withdraw(ticket_id, account_id, amount)

create_ticket的語義是獲取一個服務(wù)器端生成的唯一的處理號ticket_id，它將用于標識后續(xù)的操作。idempotent_withdraw和withdraw的區(qū)別在于關(guān)聯(lián)了一個ticket_id，一個ticket_id表示的操作至多只會被處理一次，每次調(diào)用都將返回第一次調(diào)用時的處理結(jié)果。這樣，idempotent_withdraw就符合冪等性了，客戶端就可以放心地多次調(diào)用。

基于冪等性的解決方案中一個完整的取錢流程被分解成了兩個步驟：

1.調(diào)用create_ticket()獲取ticket_id；

2.調(diào)用idempotent_withdraw(ticket_id, account_id, amount)。
雖然create_ticket不是冪等的，但在這種設(shè)計下，它對系統(tǒng)狀態(tài)的影響可以忽略，加上idempotent_withdraw是冪等的，所以任何一步由于網(wǎng)絡(luò)等原因失敗或超時，客戶端都可以重試，直到獲得結(jié)果。

HTTP中的幾個請求方法

HTTP服務(wù)器至少應(yīng)該實現(xiàn)GET和HEAD方法，其他方法都是可選的

HTTP協(xié)議本身是一種面向資源的應(yīng)用層協(xié)議，但對HTTP協(xié)議的使用實際上存在著兩種不同的方式：
一種是RESTful的，它把HTTP當成應(yīng)用層協(xié)議，比較忠實地遵守了HTTP協(xié)議的各種規(guī)定；
另一種是SOA的，它并沒有完全把HTTP當成應(yīng)用層協(xié)議，而是把HTTP協(xié)議作為了傳輸層協(xié)議，然后在HTTP之上建立了自己的應(yīng)用層協(xié)議。

本文所討論的HTTP冪等性主要針對RESTful風(fēng)格的，不過正如上一節(jié)所看到的那樣，冪等性并不屬于特定的協(xié)議，它是分布式系統(tǒng)的一種特性；所以，不論是SOA還是RESTful的Web API設(shè)計都應(yīng)該考慮冪等性。

1. HTTP GET方法用于獲取資源，不應(yīng)有副作用，所以是冪等的（冪等性指的是作用于結(jié)果而非資源本身，get每次都獲取的是同一個資源的結(jié)果）。
2. HTTP DELETE方法用于刪除資源，有副作用，調(diào)用一次和多次對資源產(chǎn)生影響是相同的，它應(yīng)該滿足冪等性。
3. POST所對應(yīng)的URI并非創(chuàng)建的資源本身，而是資源的接收者。比如：POST http://www./articles的語義是在http://www./articles下創(chuàng)建一篇帖子，HTTP響應(yīng)中應(yīng)包含帖子的創(chuàng)建狀態(tài)以及帖子的URI。兩次相同的POST請求會在服務(wù)器端創(chuàng)建兩份資源，它們具有不同的URI；所以，POST方法不具備冪等性。
4. PUT所對應(yīng)的URI是要創(chuàng)建或更新的資源本身，他直接把實體部分的數(shù)據(jù)替換到服務(wù)器的資源，我們多次調(diào)用它，只會產(chǎn)生一次影響，但是有相同結(jié)果的 HTTP 方法，所以滿足冪等性。比如：PUT http://www.forum/articles/4231的語義是創(chuàng)建或更新ID為4231的帖子。對同一URI進行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有冪等性。
5. HTTP PATCH方法是非冪等的。HTTP PATCH方法只是更新部分資源，PATCH提供的實體則需要根據(jù)程序或其它協(xié)議的定義，解析后在服務(wù)器上執(zhí)行，以此來修改服務(wù)器上的資源。換句話說，PATCH請求是會執(zhí)行某個程序的，如果重復(fù)提交，程序可能執(zhí)行多次，對服務(wù)器上的資源就可能造成額外的影響，這就可以解釋它為什么是非冪等的了。
6. Head也是冪等的

總結(jié)：
GET，HEAD，PUT和DELETE方法都有這樣的冪等屬性，同樣由于根據(jù)協(xié)議，OPTIONS，TRACE都不應(yīng)有副作用，因此也理所當然也是冪等的。

Post Patch都不是冪等的。

案例與請求方法結(jié)合

在介紹了幾種操作的語義和冪等性之后，我們來看看如何通過Web API的形式實現(xiàn)前面所提到的取款功能。
很簡單，用POST /tickets來實現(xiàn)create_ticket；用PUT /accounts/account_id/ticket_id&amount=xxx來實現(xiàn)idempotent_withdraw。

值得注意的是嚴格來講amount參數(shù)不應(yīng)該作為URI的一部分，真正的URI應(yīng)該是/accounts/account_id/ticket_id，而amount應(yīng)該放在請求的body中。

這種模式可以應(yīng)用于很多場合，比如：論壇網(wǎng)站中防止意外的重復(fù)發(fā)帖。
資料：https://www.cnblogs.com/baizhanshi/p/6860061.html