最普遍的答案
我一直就覺得get和post沒有什麼除了語義之外的區別，自打我開始學習web程式設計開始就是這麼理解的。
可能很多人都已經猜到了，他要的答案是：
但是很不幸，這些區別全是錯誤的
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長度上的限制，有兩方面的原因造成：
瀏覽器。據說早期的瀏覽器會對url長度做限制。據說ie對url長度會限制在2048個字元內（流傳很廣，而且無數同事都表示認同）。但我自己試了一下是正常的。網上的東西，哪怕是wikipedia上的，也不能信。
伺服器。url長了，對伺服器處理也是一種負擔。原本乙個會話就沒有多少資料，現在如果有人惡意地構造幾個幾m大小的url，並不停地訪問你的伺服器。伺服器的最大併發數顯然會下降。另一種攻擊方式是，把告訴伺服器content-length是乙個很大的數，然後只給伺服器發一點兒資料，嘿嘿，伺服器你就傻等著去吧。哪怕你有超時設定，這種故意的次次訪問超時也能讓伺服器吃不了兜著走。有鑑於此，多數伺服器出於安全啦、穩定啦方面的考慮，會給url長度加限制。但是這個限制是針對所有http請求的，與get、post沒有關係。 安全不安全和get、post沒有關係
伺服器開放介面是基於rest理念設計的，使用的協議是http，但是傳輸的內容不是html。這不是web server，而是乙個web service）
如果乙個人一開始就做web開發，很可能把html對http協議的使用方式，當成http協議的唯一的合理使用方式。從而犯了以偏概全的錯誤。
可能有人會覺得我鑽牛角尖。我只是不喜歡模稜兩可，不喜歡邊界不清、概念不明，不喜歡「拿來主義」，也不喜歡被其它喜歡鑽牛角尖的人奚落得無地自容。
「知之為知之，不知為不知，是知也。」
GET和POST到底啥區別了
標準 答案 get使用url或cookie傳參，post則將資料放在body中 get的url會有長度上的限制，post的資料可以非常大 post比get安全，因為資料在位址列上不可見 這都是一些經典面試材料抄襲的 經典 的答案，沒有一點權威意義,不一提，今天我們就從官方rfc文件一 竟 get 和...
GET和POST到底有什麼區別？
get和post是我們web開發時最常用到的兩種http請求方法，其實http最初定義了八種方法，而這八種方法在本質上沒有任何區別。它們底層的實現也都是基於tcp ip協議，之所以定義了這麼多，只是讓http請求更加的語義化而已。如果說到區別，那也僅僅是資料傳輸形式上的差異，我們先來看一下這八種方法...
GET和POST請求到底有什麼區別？
看到這個標題，想必大部分人都已經想關掉這篇部落格了。先別急，你真的知道這兩個的區別嗎？做過web開發的朋友可能很熟悉，看到這個問題能立馬脫口而出二者的區別。看起來很標準的答案，我相信大部分的人都會這麼去回答。那麼很遺憾，恕我直言你可能對這兩種請求方式並不熟悉。實際上，get和post請求本質上並無區...