HTTP
超文本傳輸協議(HTTP)的設計目的是保證客戶機與服務器之間的通信。
HTTP 的工作方式是客戶機與服務器之間的請求-應答協議。
web 瀏覽器可能是客戶端,而計算機上的網絡應用程序也可能作爲服務器端。
舉例:客戶端(瀏覽器)向服務器提交 HTTP 請求;服務器向客戶端返回響應。響應包含關於請求的狀態信息以及可能被請求的內容。
兩種 HTTP 請求方法:GET 和 POST
HTTP中的GET,POST,PUT,DELETE就對應着對這個資源的查,改,增,刪4個操作。到這裏,大家應該有個大概的瞭解了,GET一般用於獲取/查詢資源信息,而POST一般用於更新資源信息。
- 根據HTTP規範,GET用於信息獲取,而且應該是安全的和冪等的。
-
(1). 所謂安全的意味着該操作用於獲取信息而非修改信息。換句話說,GET
請求一般不應產生副作用。就是說,它僅僅是獲取資源信息,就像數據庫查詢一樣,不會修改,增加數據,不會影響資源的狀態。 -
(2).冪等的意味着對同一URL的多個請求應該返回同樣的結果。
冪等有一下幾種定義:(一個數學或計算機學概念,常見於抽象代數中。)
對於單目運算,如果一個運算對於在範圍內的所有的一個數多次進行該運算所得的結果和進行一次該運算所得的結果是一樣的,那麼我們就稱該運算是冪等的。比如絕對值運算就是一個例子,在實數集中,有abs(a)=abs(abs(a))。
對於雙目運算,則要求當參與運算的兩個值是等值的情況下,如果滿足運算結果與參與運算的兩個值相等,則稱該運算冪等,如求兩個數的最大值的函數,有在在實數集中冪等,即max(x,x) = x。
但在實際應用中,以上2條規定並沒有這麼嚴格。引用別人文章的例子:比如,新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一批新聞,該操作仍然被認爲是安全的和冪等的,因爲它總是返回當前的新聞。從根本上說,如果目標是當用戶打開一個鏈接時,他可以確信從自身的角度來看沒有改變資源即可。
- 根據HTTP規範,POST表示可能修改變服務器上的資源的請求。繼續引用上面的例子:還是新聞以網站爲例,讀者對新聞發表自己的評論應該通過POST實現,因爲在評論提交後站點的資源已經不同了,或者說資源被修改了。
上面大概說了一下HTTP規範中GET和POST的一些原理性的問題。但在實際的做的時候,很多人卻沒有按照HTTP規範去做,導致這個問題的原因有很多,比如說:
1.很多人貪方便,更新資源時用了GET,因爲用POST必須要到FORM(表單),這樣會麻煩一點。
2.對資源的增,刪,改,查操作,其實都可以通過GET/POST完成,不需要用到PUT和DELETE。
3.另外一個是,早期的Web MVC框架設計者們並沒有有意識地將URL當作抽象的資源來看待和設計,所以導致一個比較嚴重的問題是傳統的Web MVC框架基本上都只支持GET和POST兩種HTTP方法,而不支持PUT和DELETE方法。
GET | POST | |
---|---|---|
按鈕/刷新 | 無害 | 數據會被重新提交(瀏覽器應該告知用戶數據會被重新提交) |
書籤 | 可收藏爲書籤 | 不可收藏爲書籤 |
緩存 | 能被緩存 | 不能緩存 |
編碼類型 | application/x-www-form-urlencoded | application/x-www-form-urlencoded 或 multipart/form-data。爲二進制數據使用多重編碼。 |
歷史 | 參數保留在瀏覽器歷史中。 | 參數不會保存在瀏覽器歷史中。 |
對數據長度的限制 | 是的。當發送數據時,GET 方法向 URL 添加數據;URL 的長度是受限制的(URL 的最大長度是 2048 個字符)。 | 無限制。 |
對數據類型的限制 | 只允許 ASCII 字符。 | 沒有限制。也允許二進制數據。 |
安全性 | 與 POST 相比,GET 的安全性較差,因爲所發送的數據是 URL 的一部分。在發送密碼或其他敏感信息時絕不要使用 GET ! | POST 比 GET 更安全,因爲參數不會被保存在瀏覽器歷史或 web 服務器日誌中。 |
可見性 | 數據在 URL 中對所有人都是可見的。 | 數據不會顯示在 URL 中。 |
header和data發送 | 請求時,產生一個TCP包,把header和data一起發送出去 | 請求時,產生兩個TCP包,瀏覽器先發送header,然後發送data |
參考:
http://www.w3school.com.cn/tags/html_ref_httpmethods.asp
https://www.cnblogs.com/hyddd/archive/2009/03/31/1426026.html