前言
昨天幫一位同學(xué)解決網(wǎng)絡(luò)請求的問題，發(fā)給我個接口http://www.cego168.com/mobile/iosinterface.php?act=upload&name=jay&mobile=110,用來上傳聯(lián)系人的姓名和手機(jī)號。乍一看瞬間有些懵，這不是GET請求嗎，這怎么去上傳呢，之前在開發(fā)中請求提交或者修改等操作都是用的POST請求，也就是我們常見的像這種:
URL: http://www.cego168.com/mobile/iosinterface.php
paramters: act=upload&name=jay&mobile=110
URL和參數(shù)是分開的，一直以來我都以為GET是用來獲取數(shù)據(jù)的，POST是用來提交修改數(shù)據(jù)的。帶著這個困惑查閱了國內(nèi)外眾多資料，從HTTP到GET和POST，個人總結(jié)了一些見解，請往下看：
GET請求
向指定的資源發(fā)出“顯示”請求，GET應(yīng)該是安全的且是冪等的。
注: 這里僅對“安全”做下介紹，“冪等”比較難理解，有興趣的同學(xué)可以查下，在此先不介紹
(HTTP協(xié)議聲明,對于GET方法而言，除了進(jìn)行獲取資源信息外，這些請求不應(yīng)當(dāng)再有其他意義。也就是說，這些方法應(yīng)當(dāng)被認(rèn)為是“安全的”。 客戶端可能會使用其他“非安全”方法，例如POST，PUT及DELETE，應(yīng)該以特殊的方式（通常是按鈕而不是超鏈接）告知客戶可能的后果（例如一個按鈕控制的資金交易），或請求的操作可能是不安全的（例如某個文件將被上傳或刪除）。
但是，不能想當(dāng)然地認(rèn)為服務(wù)器在處理某個GET請求時不會產(chǎn)生任何副作用。事實上，很多動態(tài)資源會把這作為其特性。這里重要的區(qū)別在于用戶并沒有請求這一副作用，因此不應(yīng)由用戶為這些副作用承擔(dān)責(zé)任。)
上面這一大段話的意思就是，GET請求應(yīng)該是一些展示類的信息，比如說今日頭條獲取新聞的展示信息，而每天這些新聞有可能發(fā)生變化，這時候請求應(yīng)該是用GET的。然后用戶可能會去參與評論，留言自己的一些觀點吐槽等，這時候就應(yīng)該是POST的方式去提交信息(稍后會介紹下POST的作用和特點)，所以總結(jié)下來，GET請求應(yīng)該滿足以下特點:
- GET 向服務(wù)器發(fā)送索取數(shù)據(jù)的請求
-
GET 將請求數(shù)據(jù)放在URL中
(如：/test/demo_form.asp?name1=value1&name2=value2) -
GET 請求理論上無長度限制
(URL不存在參數(shù)上限的問題,例如限制1024字節(jié)是特定的瀏覽器及服務(wù)器對它的限制) -
GET 請求不應(yīng)在處理敏感數(shù)據(jù)時使用
(用戶提交信息,賬號、密碼等) -
GET 請求只應(yīng)當(dāng)用于取回數(shù)據(jù)
(獲取展示類的列表如新聞列表等) - GET 請求的數(shù)據(jù)在 URL 中對所有人都是可見的
-
GET 能夠被緩存
(這就會導(dǎo)致某個你輸完賬號密碼后登陸的界面被緩存，其他人查看游覽器的歷史記錄就可以拿到你的賬號密碼了)
通過以上這些特點我們在平常開發(fā)中就能知道哪些場景中應(yīng)該用GET請求了。下面再說下POST請求：
POST請求
向指定資源提交數(shù)據(jù)，請求服務(wù)器進(jìn)行處理（例如提交表單或者上傳文件），數(shù)據(jù)被包含在請求本文中。
- POST 向服務(wù)器提交數(shù)據(jù)的一種請求
- POST 將請求數(shù)據(jù)放在消息體中
- POST 請求理論上也無長度限制，起限制作用的是服務(wù)器的處理程序的處理能力
- POST 請求不會被緩存
- POST 數(shù)據(jù)不會顯示在 URL 中
- POST 安全性比GET高
(因為請求參數(shù)不在URL中并且無法被緩存，所以參數(shù)不會被保存在瀏覽器歷史或 web 服務(wù)器日志中)
綜合以上所有特點，以及相應(yīng)的一些介紹，大致可以總結(jié)出：
GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息。
但是許多人會在更新資源時使用GET，而這樣是不合理的，所以上面這個同學(xué)發(fā)的這個接口，合理的做法是POST請求去更新數(shù)據(jù)。
