HTTP協議-get,put,post,delete含義與區別

        原文地址：http://286.iteye.com/blog/1420713

        GET操做是安全的。所謂安全是指無論進行多少次操做，資源的狀態都不會改變。好比我用GET瀏覽文章，無論瀏覽多少次，那篇文章還在那，沒有變化。固然，你可能說每瀏覽一次文章，文章的瀏覽數就加一，這不也改變了資源的狀態麼？這並不矛盾，由於這個改變不是GET操做引發的，而是用戶本身設定的服務端邏輯形成的。
        PUT，DELETE操做是冪等的。所謂冪等是指無論進行多少次操做，結果都同樣。好比我用PUT修改一篇文章，而後在作一樣的操做，每次操做後的結果並無不一樣，DELETE也是同樣。順便說一句，由於GET操做是安全的，因此它天然也是冪等的。
        POST操做既不是安全的，也不是冪等的，好比常見的POST重複加載問題：當咱們屢次發出一樣的POST請求後，其結果是建立出了若干的資源。
        安全和冪等的意義在於：當操做沒有達到預期的目標時，咱們能夠不停的重試，而不會對資源產生反作用。從這個意義上說，POST操做每每是有害的，但不少時候咱們仍是不得不使用它。
        還有一點須要注意的就是，建立操做可使用POST，也可使用PUT，區別在於POST 是做用在一個集合資源之上的（/uri），而PUT操做是做用在一個具體資源之上的（/uri/xxx），再通俗點說，若是URL能夠在客戶端肯定，那麼就使用PUT，若是是在服務端肯定，那麼就使用POST，好比說不少資源使用數據庫自增主鍵做爲標識信息，而建立的資源的標識信息究竟是什麼只能由服務端提供，這個時候就必須使用POST。
  
        關於GET POST 的混淆
        先說相同點，只有瞭解了相同點以後才能理解爲何會發生混淆。
        二者都能向服務器發送數據，提交的「內容」[注1]的格式相同，都是var_1=value_1&var_2=value_2&....  

        get 和 post 區別如字面，一個是get（獲取），一個是post（發送）。

        get用來告訴服務器須要獲取哪些內容（uri+query），向靜態頁面（uri）請求則直接返回文件內容給瀏覽器，向一個動態頁面請求時能夠提供查詢參數（query）以得到相應內容。

        post用來向服務器提交內容，主要是爲了提交，而不是爲了請求內容，就是說post的初衷並不要求服務器返回內容[注2]，只是提交內容讓服務器處理（主要是存儲或者處理以後再存儲）。

        get和post出現混淆是由於對提交的數據處理方法的濫用形成的，數據是無辜的。

        混淆之一：
        將get提交的用來查詢的字段看成是存儲數據存入了服務器端文件或者數據庫。而後就誤覺得get是用來提交用於存儲的數據的。

        混淆之二：
        編寫腳本在服務器端經過處理post提交的數據並返回內容。只要有數據，就能用來進行判斷，腳本怎寫是程序員的事，而不在意數據來源的形式（post、get，或者是本身預設值的常量）。這點功能上確實沒問題，只是背離的其初始目的而已。

        因爲都是要傳送數據，且數據格式相同（即便數據格式不一樣，只要能提取出相應數據）。使用的時候不免出現張冠李戴，將get數據用來存儲、將post數據用來檢索返回數據。可是兩者仍是有區別的（主要是根據其用途而「人爲」形成的），get的長度限制在2048字節（由瀏覽器和服務器限制的，這是目前IE的數據，曾經是1024字節），很大程度上限制了get用來傳遞「存儲數據」的數據的能力，因此仍是老老實實用來作檢索吧；post則無此限制（只是HTTP協議規範沒有進行大小限制，但受限於服務器的處理能力），所以對於大的數據（通常來講須要存儲的數據可能會比較大，比2048字節大）的傳遞有自然的優點，誰讓它是 nature born post 呢。

        get提交的數據是放在url裏，目的是靈活的向服務其提交檢索請求，能夠在地址欄隨時修改數據以變動須要獲取的內容，好比直接修改分頁的編號就跳到另一個分頁了（固然也多是 404）。post提交的數據放在http請求的正文裏，目的在於提交數據並用於服務器端的存儲，而不容許用戶過多的更改相應數據（主要是相對於在url 修改要麻煩不少，url的修改只要點擊地址欄輸入字符就能夠了），除非是專門跑來編輯數據的。

        PS：post和get的安全性在傳輸的層面上區別不大，可是採用url提交數據的get方式容易被人肉眼看到，或者出如今歷史紀錄裏，仍是可能被肉眼看到，都是一些本地的問題。

        注1：我強調的是內容，至於http協議中的get和post的格式你們有興趣就本身看看吧。
        注2：get方式主要是爲了得到預期內容，即uri+query相同時所獲得的內容應該是相同的。而post主要是提交內容，至因而否有必要返回頁面可能只是出於用戶體驗，好比註冊時返回你的註冊id，可是若是隻是返回一個「您已註冊成功」的相同頁面（即便你post的數據不同）也沒什麼好奇怪的。
        注3：關於這個「人爲」，不是那麼貼切，get和post仍是有技術層面的區別的。可是從表象上看暫且這麼說吧，畢竟兩者的混淆也是「人爲」的。

 

HTTP POST GET 本質區別 
        原理區別

        通常在瀏覽器中輸入網址訪問資源都是經過GET方式；在FORM提交中，能夠經過Method指定提交方式爲GET或者POST，默認爲GET提交 Http定義了與服務器交互的不一樣方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE URL 全稱是資源描述符，咱們能夠這樣認爲：一個URL地址，它用於描述一個網絡上的資源，而HTTP中的GET，POST，PUT，DELETE就對應着對這個資源的查 ，改 ，增 ，刪 4個操做。到這裏，你們應該有個大概的瞭解了，GET通常用於獲取/查詢 資源信息，而POST通常用於更新 資源信息(我的認爲這是GET和POST的本質區別，也是協議設計者的本意，其它區別都是具體表現形式的差別 )。 　　         根據HTTP規範，GET用於信息獲取，並且應該是安全的和冪等的 。 　　         1.所謂安全的意味着該操做用於獲取信息而非修改信息。換句話說，GET請求通常不該產生反作用。就是說，它僅僅是獲取資源信息，就像數據庫查詢同樣，不會修改，增長數據，不會影響資源的狀態。 　　 * 注意：這裏安全的含義僅僅是指是非修改信息。 　　         2.冪等的意味着對同一URL的多個請求應該返回一樣的結果。這裏我再解釋一下冪等 這個概念： 　　 冪等 （idempotent、idempotence）是一個數學或計算機學概念，常見於抽象代數中。 　　         冪等有如下幾種定義：對於單目運算，若是一個運算對於在範圍內的全部的一個數屢次進行該運算所得的結果和進行一次該運算所得的結果是同樣的，那麼咱們就稱該運算是冪等的。好比絕對值運算就是一個例子，在實數集中，有abs(a) = abs(abs(a)) 。 　　         對於雙目運算，則要求當參與運算的兩個值是等值的狀況下，若是知足運算結果與參與運算的兩個值相等，則稱該運算冪等，如求兩個數的最大值的函數，有在在實數集中冪等，即max(x,x) = x 。 看完上述解釋後，應該能夠理解GET冪等的含義了。 　　         但在實際應用中，以上2條規定並無這麼嚴格。引用別人文章的例子：好比，新聞站點的頭版不斷更新。雖然第二次請求會返回不一樣的一批新聞，該操做仍然被認爲是安全的和冪等的，由於它老是返回當前的新聞。從根本上說，若是目標是當用戶打開一個連接時，他能夠確信從自身的角度來看沒有改變資源便可。          根據HTTP規範，POST表示可能修改變服務器上的資源的請求 。繼續引用上面的例子：仍是新聞以網站爲例，讀者對新聞發表本身的評論應該經過POST實現，由於在評論提交後站點的資源已經不一樣了，或者說資源被修改了。 　　         上面大概說了一下HTTP規範中，GET和POST的一些原理性的問題。但在實際的作的時候，不少人卻沒有按照HTTP規範去作，致使這個問題的緣由有不少，好比說： 　　                 1.不少人貪方便，更新資源時用了GET，由於用POST必需要到FORM（表單），這樣會麻煩一點。　　         2.對資源的增，刪，改，查操做，其實均可以經過GET/POST完成，不須要用到PUT和DELETE。 　　         3.另一個是，早期的可是Web MVC框架設計者們並無有意識地將URL看成抽象的資源來看待和設計 。還有一個較爲嚴重的問題是傳統的Web MVC框架基本上都只支持GET和POST兩種HTTP方法，而不支持PUT和DELETE方法。