- POST /uri 創建
- DELETE /uri/xxx 刪除
- PUT /uri/xxx 更新或創建
- 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方法。
https://www.cnblogs.com/zhangpengshou/archive/2012/07/09/2583096.html