html/css基礎篇——GET和POST的區別

　　本文前面部分轉自木-葉的博文，後面有本人本身的一些總結和體會。

　　

 若是有人問你，GET和POST，有什麼區別？你會如何回答？

個人經歷

     前幾天有人問我這個問題。我說GET是用於獲取數據的，POST，通常用於將數據發給服務器之用。

    這個答案好像並非他想要的。因而他繼續追問有沒有別的區別？我說這就是個名字而已，若是服務器支持，他徹底能夠把GET改個名字叫GET2。他反問道，那就是單純的名字上的區別嘍？我想了想，我以爲若是說再具體的區別，只能去看RFC文檔了，還要取決於服務器（指Apache，IIS）的具體實現。但我不得不認可，個人確沒有仔細看過HTTP的RFC文檔。因而我說，我對HTTP協議不太熟悉。這個問題也就結束了。

最廣泛的答案

     回來以後尋思了好久，他究竟是想問我什麼？我一直就以爲GET和POST沒有什麼除了語義以外的區別，自打我開始學習Web編程開始就是這麼理解的。

     可能不少人都已經猜到了，他要的答案是：

1. GET使用URL或Cookie傳參。而POST將數據放在BODY中。

2. GET的URL會有長度上的限制，則POST的數據則能夠很是大。

3. POST比GET安全，由於數據在地址欄上不可見。

     可是很不幸，這些區別全是錯誤的，更不幸的是，這個答案仍是Google搜索的頭版頭條，然而我根本沒想着這些是答案，由於在我看來他們都是錯的。我來一一解釋一下。

GET和POST與數據如何傳遞沒有關係

     GET和POST是由HTTP協議定義的。在HTTP協議中，Method和Data（URL， Body， Header）是正交的兩個概念，也就是說，使用哪一個Method與應用層的數據如何傳輸是沒有相互關係的。

     HTTP沒有要求，若是Method是POST數據就要放在BODY中。也沒有要求，若是Method是GET，數據（參數）就必定要放在URL中而不能放在BODY中。

     那麼，網上流傳甚廣的這個說法是從何而來的呢？我在HTML標準中，找到了類似的描述。這和網上流傳的說法一致。可是這只是HTML標準對HTTP協議的用法的約定。怎麼能當成GET和POST的區別呢？

    並且，現代的Web Server都是支持GET中包含BODY這樣的請求。雖然這種請求不可能從瀏覽器發出，可是如今的Web Server又不是隻給瀏覽器用，已經徹底地超出了HTML服務器的範疇了。

     知道這個有什麼用？我不想解釋了，有時候就得本身痛一次才記得住。

HTTP協議對GET和POST都沒有對長度的限制

     HTTP協議明確地指出了，HTTP頭和Body都沒有長度的要求。而對於URL長度上的限制，有兩方面的緣由形成：

     1. 瀏覽器。聽說早期的瀏覽器會對URL長度作限制。聽說IE對URL長度會限制在2048個字符內（流傳很廣，並且無數同事都表示認同）。但我本身試了一下，我構造了90K的URL經過IE9訪問live.com，是正常的。網上的東西，哪怕是Wikipedia上的，也不能信。

     2. 服務器。URL長了，對服務器處理也是一種負擔。本來一個會話就沒有多少數據，如今若是有人惡意地構造幾個幾M大小的URL，並不停地訪問你的服務器。服務器的最大併發數顯然會降低。另外一種攻擊方式是，把告訴服務器Content-Length是一個很大的數，而後只給服務器發一點兒數據，嘿嘿，服務器你就傻等着去吧。哪怕你有超時設置，這種故意的次次訪問超時也能讓服務器吃不了兜着走。有鑑於此，多數服務器出於安全啦、穩定啦方面的考慮，會給URL長度加限制。可是這個限制是針對全部HTTP請求的，與GET、POST沒有關係。

安全不安全和GET、POST沒有關係

     我以爲這真是中國特點。我講個小段子，你們應該能夠體會出這個說法多麼的好笑。

      以爲POST數據比GET數據安全的人會說

    「防君子不防小人；中國小白多，能防小白用戶就好了。」

    「哼，」我不覺得然，「那你怎麼不說，URL參數都Encode過了，或是Base64一下，小白也看不懂啊。」

     那人反駁道，「Encode太簡單了，聰明點兒的小白很容易就能夠Decode並修改掉。」

     我笑道，「五十步笑百步耳，再聰明點兒的小白還會截包並重發呢，Opera就有這功能。」

     那人陰險地祭出神器——最終解釋權，說，「這個不算小白。」

     我日啊。

最後一點兒感想

     我以前一直作Windows桌面應用，對Web開發無甚瞭解，直到一年多前轉作服務器端開發，纔開始接觸到HTTP。（注意，我說的是HTTP，不是HTML。服務器開放接口是基於REST理念設計的，使用的協議是HTTP，可是傳輸的內容不是HTML。這不是Web Server，而是一個Web Service）

     因此我對於GET和POST的理解，是純粹地來源於HTTP協議。他們只有一點根本區別，簡單點兒說，一個用於獲取數據，一個用於修改數據。具體的請參考RFC文檔。

     若是一我的一開始就作Web開發，極可能把HTML對HTTP協議的使用方式，當成HTTP協議的惟一的合理使用方式。從而犯了以偏概全的錯誤。

     可能有人會以爲我鑽牛角尖。我只是不喜歡模棱兩可，不喜歡邊界不清、概念不明，不喜歡「拿來主義」，也不喜歡被其它喜歡鑽牛角尖的人奚落得無地自容。

     「知之爲知之，不知爲不知，是知也。」

 

　　上面文章是轉載的，最後說一點get和post的一點差別吧。

---

 

　　首先在使用上，仍是嚴格遵照

　　 GET - 從指定的服務器中獲取數據

　　POST - 提交數據給指定的服務器處理

 

　　而後說說他們的一些差異：

　　 GET　

1. GET查詢字符串（鍵值對）被附加在URL地址後面一塊兒發送到服務器
2. GET請求可以被緩存
3. GET請求會保存在瀏覽器的瀏覽記錄中
4. 以GET請求的URL可以保存爲瀏覽器書籤

　　POST

1. POST查詢字符串被放在POST信息中的一個單獨地方和HTTP請求一塊兒發送到服務器.
2. POST請求不能被緩存下來
3. POST請求不會保存在瀏覽器瀏覽記錄中
4. 以POST請求的URL沒法保存爲瀏覽器書籤

　　至於URL的長度限制，有轉載文章中指出了，服務器爲了不惡意url請求可能會作限制，標準中並無限制條款。

　　另外url中不容許出現ASCII字符類型之外的字符，body中的數據則沒有要求

　　安全性上來講，實際上二者的數據均可以被截取，只是get直接就在url就可截取，post麻煩一些而已，正如轉文所說，防君子而不防小人。

　　

　　get請求可以被緩存的這個特色實際上被瀏覽器用的很好，好比咱們日常看到的標籤<img src='xxx'/>就是使用的get請求，而後緩存圖片，下次請求就不用在從服務器端傳遞圖片過來了。下面兩張圖片對比第一次請求圖片和第二次請求圖片(刷一次頁面)

　　

　　對比兩次60k和200b差距何其大。因此使用的時候綜合考慮get和post的優缺點來使用，讓網站更加高效。

　　

　　若是以爲本文不錯，請點擊右下方【推薦】！