為什麼刪除的請求要使用POST或者DELETE

一、前言

最近在專案開發時遇到這樣一個業務請求：一個基礎模組的刪除操作。當時在寫controller時，下意識地寫成了下面的樣子：

    @GetMapping("/deleteById")     public R deleteById (@RequestParam("id") Long id) {         // 相關業務處理     }

雖然我沒有嚴格遵循RESTFUL風格的寫法，但是使用get請求刪除資料還是有些怪怪的！

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

二、GET，DELETE，PUT和POST

2.1、GET請求

2.2、POST請求

2.3、PUT請求

2.4、DELETE請求

三、GET請求是真正安全的嗎？

上面已經寫到GET請求是安全且冪等的了，為什麼還會有這樣個疑問呢？其實上面的描述是嚴格準守RESTFUL風格的寫法，GET請求僅用於獲取資料資訊，但是你的get請求如果肩負起了除此之外的功能的時候就需要特別注意了！

3.1、 get請求攜帶重要資訊

由於get請求是直接顯示在位址列的，如果請求攜帶了敏感資訊，會有暴露的風險。

PS: 你剛登陸完一個網站，在跳轉到個人中心時，位址列就把你的密碼、銀行卡號、餘額等資訊赤裸裸地展示在了位址列上面...

3.2、容易被劫持、盜刷

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

PS: 刪除資料的介面是使用GET請求，我直接從位址列中拿到連線，給你從0到999的資料都請求一遍，甚至寫個指令碼無限請求...

3.3、請求內容限制

GET請求是有長度限制的，相較於POST請求，它的攜帶資料會更小

3.4、其他安全隱患

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

四、後記

說了這麼多，我們可以總結如下：

① GET請求無罪，關鍵還是怎麼去使用它

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

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