既然get和post是有關http請求的兩種方式，就先來看看http請求報文和響應報文的知識。 超文字傳輸協議(hypertext transfer protocol，簡稱http)是應用層協議。http 是一種請求/響應式的協議，即乙個客戶端與伺服器建立連線後，向伺服器傳送乙個請求;伺服器接到請求後，給予相應的響應資訊。http請求報文由請求行、請求頭部、空行和請求體組成，如下圖所示：
請求行
請求行由請求方法、url、協議版本組成，由空格隔開。常用的http請求方法有get、post、head、put、delete、options、trace、connect。常用的有get和post，就是這篇博文需要區分的兩種方式，下面先從http協議的角度做乙個簡單的說明：
請求頭部
請求頭部由關鍵字/值對組成，關鍵字和值用英文冒號「:」分隔。請求頭部通知伺服器有關於客戶端請求的資訊，典型的請求頭有：
請求體
請求體一般不在get方法中使用，而是在post方法中使用（比如提交的表單資料放在請求體中）。與請求體相關的最常使用的請求頭是content-type和content-length;
響應報文由狀態行、響應頭部、空行和響應體組成，如下圖所示：
狀態行
狀態行由伺服器http協議版本，響應狀態碼，狀態碼的文字描述組成。
狀態碼由3位數字組成，第乙個數字定義了響應的類別
響應包體
伺服器返回給客戶端的文字資訊。
上面說了這麼多，可以知道get和post就是http協議中請求報文的請求行中標識客戶端的兩種不同的請求方式。也就是說get和post 只是http協議中兩種請求方式，而http協議是基於tcp/ip的應用層協議，無論get還是post，用的都是同乙個傳輸層協議，所以在傳輸上沒有區別。只是由於http的規定和瀏覽器/伺服器的限制，導致他們在應用過程中體現出了一些不同之處。如果不按規範來也是可以的，可以在url上寫引數，然後方法使用post；也可以在請求體中寫引數，然後方法使用get。當然，這需要服務端支援。
1. 請求引數存放位置的差異
get請求的引數是跟著url後面的，請求行格式為：get /url?id=1&type=0 http/1.1。post請求的引數是放在請求體中的。這並不是硬性規定，只是一種規範。
2. 請求引數長度的限制
首先要明確說明，http協議本身對著請求體和url的長度是沒有限制的，對url限制的大多是瀏覽器和伺服器的原因。
從伺服器的角度說，處理長url要消耗較多的資源，為了效能和安全（防止惡意構造長url來攻擊）考慮，會給url長度加限制。ie瀏覽器對url的最大限制為2083個字元，如果超過這個數字，提交按鈕沒有任何反應。firefox瀏覽器url的長度限制為65536個字元。safari url最大長度限制為80000個字元。opera url最大長度限制為190000個字元。google url最大長度限制為8182個字元。此外，除了瀏覽器的限制，還有web伺服器的限制，即使用firefox並不一定能傳送長度為65536的url，而是還收到伺服器的限制，若伺服器能接受的url長度比65536小，則只能以伺服器為準。apache server能接受最大url長度為8192個字元。iis能接受最大url的長度為16384個字元。nginx伺服器預設的限制是4k或者8k，這是根據伺服器的硬體配置有關的，一般為記憶體一頁的大小，目前大部分為4k，。
3. 安全性和冪等性
從傳輸的角度來說，他們都是不安全的，因為http在網路上是明文傳輸的，只要在網路節點上捉包，就能完整地獲取資料報文。要想安全傳輸，就只有加密，也就是https。
從http設計規範上看，get用於資訊獲取，不對伺服器上的資源做修改，post表示可能修改變伺服器上的資源的請求。所謂安全的意味著該操作用於獲取資訊而非修改資訊。當然你也可以將get用於往資料庫中插入一條資料，資料內容放在url上，你的form表單的提交也可以是get請求，只是這很不規範。所以get被認為比post安全。
由於get請求引數會暴露在url中，瀏覽器頁面快取或者歷史記錄等會被他人看到，因此隱私資料如密碼可能會被洩露。此外，get請求提交的資料還可能會造成cross-site request frogery攻擊。所以post被認為比get安全。
冪等 （idempotent、idempotence）是乙個數學或計算機學概念，常見於抽象代數中。
冪等有以下幾種定義：
對於單目運算，如果乙個運算對於在範圍內的所有的乙個數多次進行該運算所得的結果和進行一次該運算所得的結果是一樣的，那麼我們就稱該運算是冪等的。 比如絕對值運算就是乙個例子，在實數集中，有abs(a) = abs(abs(a)) 。
對於雙目運算，則要求當參與運算的兩個值是等值的情況下，如果滿足運算結果與參與運算的兩個值相等，則稱該運算冪等，如求兩個數的最大值的函式，有在實數集中冪等，即max(x,x) = x 。
但在實際應用中，以上2條規定並沒有這麼嚴格。比如新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認為是安全的和冪等的，因為它總是返回當前的新聞。
4. 產生的資料報個數
有些文章中提到，post會將header和body分開傳送，先傳送header，服務端返回100狀態碼再傳送body。
http協議中沒有明確說明post會產生兩個tcp資料報，而且實際測試(chrome)發現，header和body不會分開傳送。
但是確實是有發兩個包的情況的，可並不是先發post的header，返回乙個100繼續傳送body，而是先發乙個tcp包，把header發過去，然後因為nagle演算法的原因，就等待乙個tcp的ack，然後再發剩下的包。
具體看
5. 其他
這才是真正的「匈牙利命名法」
從剛進大學開始學習 c 語言，就聽說了實際開發中會用到的各種變數命名方法，例如常見的匈牙利命名法 駱駝命名法 pascal 命名法等。後來自己真正開始用 c c 寫程式，開始使用匈牙利命名法，總覺得十分彆扭。好好的變數名 name，嚴格按照命名規則，非得在前面加型別字首，改寫成 lpszname。如...
GET和POST的真正區別
http定義了與伺服器互動的不同方法，最基本的方法有4種，分別是get，post，put，delete。url全稱是資源描述符，我們可以這樣認為 乙個url位址，它用於描述乙個網路上的資源，而http中的get，post，put，delete就對應著對這個資源的 查，改，增，刪4個操作。到這裡，大家...
這才是智慧型家居真正的現狀
近期有 就長沙智慧型家居現狀進行調查，結果顯示，近8成不了解智慧型家居系統，新房裝修時，近6成表示不會考慮使用智慧型家居。儘管是以長沙這麼乙個三線城市作為範本，也反映了智慧型家居尷尬的現狀。發展二十載，智慧型家居前景一直被無限渲染，不然谷歌 蘋果 亞馬遜等國際巨頭不會耗費巨資乙個勁的深入這個行業。據...