解釋程式碼 

1. POST   /uri     建立  
2. DELETE /uri/xxx 刪除   
3. PUT    /uri/xxx 更新或建立  
4. GET    /uri/xxx 檢視  

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資料用來檢索返回資料。但是二者還是有區別的（主要是根據其用途而“人為”[注3]造成的），get的長度限制在2048位元組（由瀏覽器和伺服器限制的，這是目前IE的資料，曾經是1024位元組），很大程度上限制了get用來傳遞“儲存資料”的資料的能力，所以還是老老實實用來做檢索吧；post則無此限制（只是HTTP協議規範沒有進行大小限制，但受限於伺服器的處理能力），因此對於大的資料（一般來說需要儲存的資料可能會比較大，比2048位元組大）的傳遞有天然的優勢，誰讓它是 nature born post 呢。

get提交的資料是放在url裡，目的是靈活的向服務其提交檢索請求，可以在位址列隨時修改資料以變更需要獲取的內容，比如直接修改分頁的編號就跳到另外一個分頁了（當然也可能是 404）。post提交的資料放在http請求的正文裡，目的在於提交資料並用於伺服器端的儲存，而不允許使用者過多的更改相應資料（主要是相對於在url 修改要麻煩很多，url的修改只要點選位址列輸入字元就可以了），除非是專門跑來編輯資料的。

花邊：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方法。