IOS http請求的get 和 post的請求的區別

標籤：ios   http   get   

從表面的意思看get 和 post的區別get就是擷取資料，post就是發送資料。這個是誤區。其實兩者都可以的，在IOS向伺服器發送請求裡面可以帶參數。

那麼這些誤區是怎麼出現的呢？先看看一下對http的解釋

一般在瀏覽器中輸入網址訪問資源都是通過GET方式；在FORM提交中，可以通過Method指定提交方式為GET或者POST，預設為GET提交 
Http定義了與伺服器互動的不同方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE 
URL全稱是資源描述符，我們可以這樣認為：一個URL地址，它用於描述一個網路上的資源，而HTTP中的GET，POST，PUT，DELETE就對應著對這個資源的查 ，改 ，增 ，刪 4個操作。到這裡，大家應該有個大概的瞭解了，GET一般用於擷取/查詢 資源資訊，而POST一般用於更新 資源資訊(個人認為這是GET和POST的本質區別，也是協議設計者的本意，其它區別都是具體表現形式的差異 )。

再進一步瞭解下他們兩個的區別：

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

2. GET的URL會有長度上的限制，則POST的資料則可以非常大。

3. POST比GET安全，因為資料在地址欄上不可見。

這些也是有點誤區的，就像同步請求一定的慢嗎？

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沒有關係。

這個貌似聽著對點吧。

3.對於安全不安全講。

get:

.所謂安全的意味著該操作用於擷取資訊而非修改資訊。換句話說，GET請求一般不應產生副作用。就是說，它僅僅是擷取資源資訊，就像資料庫查詢一樣，不會修改，增加資料，不會影響資源的狀態。 
* 注意：這裡安全的含義僅僅是指是非修改資訊。

 

POST的安全性要比GET的安全性高。注意：這裡所說的安全性和上面GET提到的“安全”不是同個概念。上面“安全”的含義僅僅是不作資料修改，而這裡安全的含義是真正的Security的含義，比如：通過GET提交資料，使用者名稱和密碼將明文出現在URL上，因為(1)登入頁面有可能被瀏覽器緩衝， (2)其他人查看瀏覽器的曆史紀錄，那麼別人就可以拿到你的帳號和密碼了，除此之外，使用GET提交資料還可能會造成Cross-site request forgery攻擊 .

看出來區別了吧

IOS http請求的get 和 post的請求的區別