在RESTful看來, 刪除肯定是發DELETE請求, 刪除一條記錄沒什么問題, 直接把id附在路徑上, 但如果要做批量刪除, 路徑里不能放一個數組, 該如何實現呢?
這時想起一個知識盲點: DELETE請求能帶請求體嗎?
答案是可以, HTTP 1.1沒規定DELETE請求不能帶請求體, 但同時又規定, 沒規定不能帶請求體的, 收到這種請求時默認給你忽略掉請求體。繞了一圈, 簡直然並卵, 結論就是不要在DELETE請求帶請求體。
那有人就直接改POST請求出去了, 這時又有點擔心不夠RESTful, 畢竟是刪除啊...
我們公司的處理辦法是, 如果是在分頁的頁面上全選, 畢竟選中的記錄數有限, 可以把ids的數組轉字符串放在DELETE請求后, 后台按照分隔符解析還原成數組, 然后處理一個個id的刪除請求。這種方法一般不至於長度撐爆URL, 但也使用不多。另外一種就是改發PUT請求, 這就意味着不是要對記錄做刪除, 而是更新處理。從PUT的請求體中拿ids數組,將每個id實體在數據庫中有對應的標志位置為0表示刪除, 這種邏輯刪除是比較常見的解決辦法, 又不至於違背RESTful風格。
回頭一想, 增刪改本來就可以都看作更新, 其實說到底還是POST那一套。RESTful在統一規范路徑的格式上做出貢獻, 讓請求的URL不再那么天馬行空, 但還是有需要完善的地方。
據說HTTP 2.0在2013年8月就開始測試, 只適用於https協議，而http://網址將繼續使用HTTP/1。大部分瀏覽器廠商在2015年底都做到了支持HTTP/2，但它的主要目標是改進傳輸性能，實現低延遲和高吞吐量。HTTP的高層協議語義並沒有因為版本升級而受影響，所有HTTP請求頭、請求體，以及它們的使用場景都仍然沿用。