一、前言

最近在項目開發(fā)時遇到這樣一個業(yè)務(wù)請求：一個基礎(chǔ)模塊的刪除操作。當時在寫controller時，下意識地寫成了下面的樣子：

@GetMapping("/deleteById")publicRdeleteById(@RequestParam("id")Longid){//相關(guān)業(yè)務(wù)處理}

雖然我沒有嚴格遵循RESTFUL風(fēng)格的寫法，但是使用get請求刪除數(shù)據(jù)還是有些怪怪的！

你肯定看到過這樣的文章“新公司要求接口全部適用POST請求”、“同事因為一個GET請求造成線上Blocker級BUG”。這些問題都最終指向了一個最終的交匯點：Get請求真的那么的不安全嗎？為什么？

二、GET，DELETE，PUT和POST2.1、GET請求2.2、POST請求2.3、PUT請求2.4、DELETE請求三、GET請求是真正安全的嗎？

上面已經(jīng)寫到GET請求是安全且冪等的了，為什么還會有這樣個疑問呢？其實上面的描述是嚴格準守RESTFUL風(fēng)格的寫法，GET請求僅用于獲取數(shù)據(jù)信息，但是你的get請求如果肩負起了除此之外的功能的時候就需要特別注意了！

3.1、 get請求攜帶重要信息

由于get請求是直接顯示在地址欄的，如果請求攜帶了敏感信息，會有暴露的風(fēng)險。

PS: 你剛登陸完一個網(wǎng)站，在跳轉(zhuǎn)到個人中心時，地址欄就把你的密碼、銀行卡號、余額等信息赤裸裸地展示在了地址欄上面...

3.2、容易被劫持、盜刷

如果你的網(wǎng)站安全需求度高，且關(guān)鍵操作使用了GET請求，則給自己增加了隱患。

PS: 刪除數(shù)據(jù)的接口是使用GET請求，我直接從地址欄中拿到連接，給你從0到999的數(shù)據(jù)都請求一遍，甚至寫個腳本無限請求...

3.3、請求內(nèi)容限制

GET請求是有長度限制的，相較于POST請求，它的攜帶數(shù)據(jù)會更小

3.4、其他安全隱患

再如上面的情況，你的一個刪除的接口使用了GET請求，又恰巧被爬蟲訪問、或是被收錄了。這就...

四、后記

說了這么多，我們可以總結(jié)如下：

① GET請求無罪，關(guān)鍵還是怎么去使用它

② 不推薦GET請求肩負起獲取信息之外的功能操作

③ 如果對安全等級要求過高，慎用GET請求