我們會經(jīng)?？吹接腥藛枺篽ttp協(xié)議中GET請求和POST請求有什么區(qū)別~？

　　這個問題看似很簡單，但是不同程度的人會回答出不同的結果。在公司的面試中，也會經(jīng)常的問及類似這樣的問題，看似很簡單，但是不同層次的人會回答出不同的結果。那么我們今天就來聊聊HTTP協(xié)議中GET與POST的真正區(qū)別。

　　我們還是要用一句簡練的話來回答GET和POST的區(qū)別：

　　提及GET和POST的區(qū)別，一定要確定基于什么前提。在不同的前提下有不同的答案。

　　這么簡單的GET和POST背后有什么神秘的面紗呢？我們今天依然用鄧哥的例子來講給大家~

　　鄧哥家住在吃雞村，鄧嫂家住在農(nóng)藥屯。鄧哥到鄧嫂家可以有很多種選擇，走著去、駕車去、坐火車去等等。鄧哥通常選擇駕車過去。

　　這里吃雞村和農(nóng)藥屯就相當于是互聯(lián)網(wǎng)中的兩臺計算機，鄧哥和鄧嫂相當于是這兩臺計算機中的兩個程序，這兩個程序之間想要通信可以有很多種協(xié)議，就好比有很多種交通方式可以到達。我們假設駕車這種方式就是網(wǎng)絡中的HTTP協(xié)議。

　　鄧哥家有兩輛車，一輛轎車，一輛箱式貨車。

　　兩種車就好比是HTTP協(xié)議中的兩種方式，我們假設轎車是GET請求方式，箱式貨車是POST請求方式。

　　有一天鄧哥想接鄧嫂來吃雞村玩，鄧哥準備開箱式貨車去接鄧嫂。

　　鄧哥要去接鄧嫂，就好比程序A要向程序B發(fā)出一個請求。從原理上說，無論是轎車還是貨車都是車，都能夠把人接回來。所以在本質(zhì)上，GET請求和POST請求都能拉取數(shù)據(jù)。

　　這時候，鄧哥的父親（也就是隔壁老王）出來了，說道：“你是不是傻，去接人開轎車多好啊，開貨車干嘛？費油不說，沒準人家那還不讓貨車停車呢！”

　　既然GET和POST都可以做到拉取數(shù)據(jù)，那么為什么我們通常拉取數(shù)據(jù)使用GET而不使用POST呢？

　　在故事中，隔壁老王不讓鄧哥開卡車去接鄧嫂，那么在現(xiàn)實中，是不是也有一個“隔壁老王”這樣的角色在限制我們呢？

　　答案是：有的！這個現(xiàn)實中的“隔壁老王”就是ISO國際標準化組織，這個組織也說了一堆類似隔壁老王的話，這堆話被稱為RFC規(guī)范。

　　所以說，我們常說的HTTP協(xié)議實際上是基于RFC規(guī)范的，實際上GET和POST請求的語法是完全相同的，但是在RFC規(guī)范中，給GET請求和POST請求規(guī)定了語義，規(guī)定GET用來獲取信息，POST用來發(fā)送信息。

　　當過年的時候，鄧哥想要給鄧嫂家送一些年貨的時候，鄧哥按照隔壁老王的囑咐，開著貨車給鄧嫂家送年貨去了。當然，送過去了一些蔬菜也會稍微拉回來一點水果~

　　這就是按照RFC的規(guī)范來執(zhí)行的，當鄧哥想要送年貨的時候，就會開貨車過去；在互聯(lián)網(wǎng)環(huán)境中，如果想要發(fā)送信息就要使用POST方法。

　　POST方法雖然是發(fā)送消息的，但也是有Response的，在請求返回的時候帶回來一點數(shù)據(jù)也是被允許的。

　　那么這時候問題又來了，鄧哥如果不聽老王的怎么辦？那這個規(guī)范不就沒有作用了嗎？這個時候老王也是很有辦法的，老王就坐在院子門口，如果鄧哥想運貨出去的時候，開的不是貨車就不讓出院門~

　　光有規(guī)范沒有具體的軟件實施也是沒有意義的，所以很多的軟件遵從了RFC的規(guī)范，比如我們熟悉的Chrome瀏覽器。所以我們想用GET方式發(fā)送文件或者圖片是不可能的~就像鄧哥不可能用轎車去給鄧嫂送年貨一樣。

　　所以我們最后來總結一下：

　　當人們問起GET和POST的區(qū)別時，我們要先確定，這里的GET和POST是基于什么前提的？

　　1. 如果什么前提都沒有，也就是不用任何規(guī)范限制的話，我們只考慮語法來說，這兩個方式是沒有任何區(qū)別的，只有名字不一樣。

　　2. 如果是基于RFC規(guī)范的，那么問題就又來了。是基于RFC理論的，還是基于具體的實現(xiàn)的。

　?。?）如果是基于RFC理論的，我們稱這個為Specification。那么GET和POST是具有相同的語法，但是不具備相同的語義，GET方式用作獲取信息，POST方式用作發(fā)送信息。

　?。?）如果是基于RFC的具體實現(xiàn)的，我們稱之為implementation。其實要區(qū)分是具體的哪一種實現(xiàn)。我們通常默認指的是瀏覽器實現(xiàn)的RFC。當然不止瀏覽器，我們?nèi)魏稳硕伎梢栽O計一個HTTP協(xié)議的接口，使用RFC規(guī)范，當然這些是我們不用考慮的，因為并不通用。

　　所以我們只需要考慮瀏覽器實現(xiàn)的RFC，或者說Web環(huán)境下的RFC。這個前提下的答案，就是我們最常見的那些。我就簡單的列舉在下面了~

　　a) GET的數(shù)據(jù)在 URL 中對所有人都是可見的。POST的數(shù)據(jù)不會顯示在 URL 中。

　　b) GET對數(shù)據(jù)長度有限制，當發(fā)送數(shù)據(jù)時，GET 方法向 URL 添加數(shù)據(jù)；URL 的長度是受限制的（URL 的最大長度是 2048 個字符）。POST無限制。

　　c) GET可收藏為書簽，POST不可收藏為書簽。

　　d) GET后退按鈕/刷新無影響，POST數(shù)據(jù)會被重新提交（瀏覽器應該告知用戶數(shù)據(jù)會被重新提交）。

　　e) GET編碼類型application/x-www-form-url，POST編碼類型encodedapplication/x-www-form-urlencoded 或 multipart/form-data。為二進制數(shù)據(jù)使用多重編碼。

　　f) GET歷史參數(shù)會保留在瀏覽器歷史中。POST參數(shù)不會保存在瀏覽器歷史中。

　　g) GET只允許 ASCII 字符。POST沒有限制。也允許二進制數(shù)據(jù)。

　　h) 與 POST 相比，GET 的安全性較差，因為所發(fā)送的數(shù)據(jù)是 URL 的一部分。在發(fā)送密碼或其他敏感信息時絕不要使用 GET ！POST 比 GET 更安全，因為參數(shù)不會被保存在瀏覽器歷史或 web 服務器日志中。

　　以上這些點都是我們常見的，還有一些我們不常見的，比如GET請求只會有一次TCP連接，而POST請求會有兩次TCP連接。在這背后也有許多的設計和考慮~

　　所以在我們不要認為GET和POST請求有什么區(qū)別是一個很簡單的問題哦~很多簡單的問題背后都有著很復雜的背景。

　　其實這也提醒著我們在學習和生活中不要失去好奇心。就像我們?yōu)槭裁词钦驹诘厍蛏隙皇秋h在空中？太陽為什么總是東升西落？天空為什么是藍色的而不是其他顏色？為什么人類都有眼睛鼻子和嘴？

　　很多我們認為是理所當然的背后都有著它理所當然的道理。也許這個道理就是另一個全新世界的大門~！希望你能夠在這個浮躁的世界中保持著一顆純潔的好奇心~！