- POST /uri 創(chuàng)建
- DELETE /uri/xxx 刪除
- PUT /uri/xxx 更新或創(chuàng)建
- GET /uri/xxx 查看
GET操作是安全的。所謂安全是指不管進(jìn)行多少次操作，資源的狀態(tài)都不會(huì)改變。比如我用GET瀏覽文章，不管瀏覽多少次，那篇文章還在那，沒有變化。當(dāng)然，你可能說每瀏覽一次文章，文章的瀏覽數(shù)就加一，這不也改變了資源的狀態(tài)么？這并不矛盾，因?yàn)檫@個(gè)改變不是GET操作引起的，而是用戶自己設(shè)定的服務(wù)端邏輯造成的。
PUT，DELETE操作是冪等的。所謂冪等是指不管進(jìn)行多少次操作，結(jié)果都一樣。比如我用PUT修改一篇文章，然后在做同樣的操作，每次操作后的結(jié)果并沒有不同，DELETE也是一樣。順便說一句，因?yàn)镚ET操作是安全的，所以它自然也是冪等的。
POST操作既不是安全的，也不是冪等的，比如常見的POST重復(fù)加載問題：當(dāng)我們多次發(fā)出同樣的POST請求后，其結(jié)果是創(chuàng)建出了若干的資源。
安全和冪等的意義在于：當(dāng)操作沒有達(dá)到預(yù)期的目標(biāo)時(shí)，我們可以不停的重試，而不會(huì)對資源產(chǎn)生副作用。從這個(gè)意義上說，POST操作往往是有害的，但很多時(shí)候我們還是不得不使用它。
還有一點(diǎn)需要注意的就是，創(chuàng)建操作可以使用POST，也可以使用PUT，區(qū)別在于POST 是作用在一個(gè)集合資源之上的（/uri），而PUT操作是作用在一個(gè)具體資源之上的（/uri/xxx），再通俗點(diǎn)說，如果URL可以在客戶端確定，那么就使用PUT，如果是在服務(wù)端確定，那么就使用POST，比如說很多資源使用數(shù)據(jù)庫自增主鍵作為標(biāo)識信息，而創(chuàng)建的資源的標(biāo)識信息到底是什么只能由服務(wù)端提供，這個(gè)時(shí)候就必須使用POST。
關(guān)于GET POST 的混淆
先說相同點(diǎn)，只有了解了相同點(diǎn)之后才能理解為什么會(huì)發(fā)生混淆。兩者都能向服務(wù)器發(fā)送數(shù)據(jù)，提交的“內(nèi)容”[注1]的格式相同，都是var_1=value_1&var_2=value_2&....get 和 post 區(qū)別如字面，一個(gè)是get（獲?。?，一個(gè)是post（發(fā)送）。get用來告訴服務(wù)器需要獲取哪些內(nèi)容（uri+query），向靜態(tài)頁面（uri）請求則直接返回文件內(nèi)容給瀏覽器，向一個(gè)動(dòng)態(tài)頁面請求時(shí)可以提供查詢參數(shù)（query）以獲得相應(yīng)內(nèi)容。post用來向服務(wù)器提交內(nèi)容，主要是為了提交，而不是為了請求內(nèi)容，就是說post的初衷并不要求服務(wù)器返回內(nèi)容[注2]，只是提交內(nèi)容讓服務(wù)器處理（主要是存儲(chǔ)或者處理之后再存儲(chǔ)）。get和post出現(xiàn)混淆是因?yàn)閷μ峤坏臄?shù)據(jù)處理方法的濫用造成的，數(shù)據(jù)是無辜的。 混淆之一：
將get提交的用來查詢的字段當(dāng)作是存儲(chǔ)數(shù)據(jù)存入了服務(wù)器端文件或者數(shù)據(jù)庫。然后就誤以為get是用來提交用于存儲(chǔ)的數(shù)據(jù)的。 混淆之二：
編寫腳本在服務(wù)器端通過處理post提交的數(shù)據(jù)并返回內(nèi)容。只要有數(shù)據(jù)，就能用來進(jìn)行判斷，腳本怎寫是程序員的事，而不在乎數(shù)據(jù)來源的形式（post、get，或者是自己預(yù)設(shè)值的常量）。這點(diǎn)功能上確實(shí)沒問題，只是背離的其初始目的而已。 由于都是要傳送數(shù)據(jù)，且數(shù)據(jù)格式相同（即使數(shù)據(jù)格式不同，只要能提取出相應(yīng)數(shù)據(jù)）。使用的時(shí)候難免出現(xiàn)張冠李戴，將get數(shù)據(jù)用來存儲(chǔ)、將post數(shù)據(jù)用來檢索返回?cái)?shù)據(jù)。但是二者還是有區(qū)別的（主要是根據(jù)其用途而“人為”[注3]造成的），get的長度限制在2048字節(jié)（由瀏覽器和服務(wù)器限制的，這是目前IE的數(shù)據(jù)，曾經(jīng)是1024字節(jié)），很大程度上限制了get用來傳遞“存儲(chǔ)數(shù)據(jù)”的數(shù)據(jù)的能力，所以還是老老實(shí)實(shí)用來做檢索吧；post則無此限制（只是HTTP協(xié)議規(guī)范沒有進(jìn)行大小限制，但受限于服務(wù)器的處理能力），因此對于大的數(shù)據(jù)（一般來說需要存儲(chǔ)的數(shù)據(jù)可能會(huì)比較大，比2048字節(jié)大）的傳遞有天然的優(yōu)勢，誰讓它是 nature born post 呢。 get提交的數(shù)據(jù)是放在url里，目的是靈活的向服務(wù)其提交檢索請求，可以在地址欄隨時(shí)修改數(shù)據(jù)以變更需要獲取的內(nèi)容，比如直接修改分頁的編號就跳到另外一個(gè)分頁了（當(dāng)然也可能是 404）。post提交的數(shù)據(jù)放在http請求的正文里，目的在于提交數(shù)據(jù)并用于服務(wù)器端的存儲(chǔ)，而不允許用戶過多的更改相應(yīng)數(shù)據(jù)（主要是相對于在url 修改要麻煩很多，url的修改只要點(diǎn)擊地址欄輸入字符就可以了），除非是專門跑來編輯數(shù)據(jù)的。 花邊：post和get的安全性在傳輸?shù)膶用嫔蠀^(qū)別不大，但是采用url提交數(shù)據(jù)的get方式容易被人肉眼看到，或者出現(xiàn)在歷史紀(jì)錄里，還是可能被肉眼看到，都是一些本地的問題。 注1：我強(qiáng)調(diào)的是內(nèi)容，至于http協(xié)議中的get和post的格式大家有興趣就自己看看吧。
注2：get方式主要是為了獲得預(yù)期內(nèi)容，即uri+query相同時(shí)所得到的內(nèi)容應(yīng)該是相同的。而post主要是提交內(nèi)容，至于是否有必要返回頁面可能只是出于用戶體驗(yàn)，比如注冊時(shí)返回你的注冊id，但是如果只是返回一個(gè)“您已注冊成功”的相同頁面（即使你post的數(shù)據(jù)不一樣）也沒什么好奇怪的。
注3：關(guān)于這個(gè)“人為”，不是那么貼切，get和post還是有技術(shù)層面的區(qū)別的。但是從表象上看暫且這么說吧，畢竟二者的混淆也是“人為”的。 HTTP POST GET 本質(zhì)區(qū)別
原理區(qū)別 一般在瀏覽器中輸入網(wǎng)址訪問資源都是通過GET方式；在FORM提交中，可以通過Method指定提交方式為GET或者POST，默認(rèn)為GET提交 Http定義了與服務(wù)器交互的不同方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE URL 全稱是資源描述符，我們可以這樣認(rèn)為：一個(gè)URL地址，它用于描述一個(gè)網(wǎng)絡(luò)上的資源，而HTTP中的GET，POST，PUT，DELETE就對應(yīng)著對這個(gè)資源的查 ，改 ，增 ，刪 4個(gè)操作。到這里，大家應(yīng)該有個(gè)大概的了解了，GET一般用于獲取/查詢 資源信息，而POST一般用于更新 資源信息(個(gè)人認(rèn)為這是GET和POST的本質(zhì)區(qū)別，也是協(xié)議設(shè)計(jì)者的本意，其它區(qū)別都是具體表現(xiàn)形式的差異 )。
根據(jù)HTTP規(guī)范，GET用于信息獲取，而且應(yīng)該是安全的和冪等的 。
1.所謂安全的意味著該操作用于獲取信息而非修改信息。換句話說，GET請求一般不應(yīng)產(chǎn)生副作用。就是說，它僅僅是獲取資源信息，就像數(shù)據(jù)庫查詢一樣，不會(huì)修改，增加數(shù)據(jù)，不會(huì)影響資源的狀態(tài)。
* 注意：這里安全的含義僅僅是指是非修改信息。
2.冪等的意味著對同一URL的多個(gè)請求應(yīng)該返回同樣的結(jié)果。這里我再解釋一下冪等 這個(gè)概念：
冪等 （idempotent、idempotence）是一個(gè)數(shù)學(xué)或計(jì)算機(jī)學(xué)概念，常見于抽象代數(shù)中。
冪等有以下幾種定義： 對于單目運(yùn)算，如果一個(gè)運(yùn)算對于在范圍內(nèi)的所有的一個(gè)數(shù)多次進(jìn)行該運(yùn)算所得的結(jié)果和進(jìn)行一次該運(yùn)算所得的結(jié)果是一樣的，那么我們就稱該運(yùn)算是冪等的。比如絕對值運(yùn)算就是一個(gè)例子，在實(shí)數(shù)集中，有abs(a) = abs(abs(a)) 。
對于雙目運(yùn)算，則要求當(dāng)參與運(yùn)算的兩個(gè)值是等值的情況下，如果滿足運(yùn)算結(jié)果與參與運(yùn)算的兩個(gè)值相等，則稱該運(yùn)算冪等，如求兩個(gè)數(shù)的最大值的函數(shù)，有在在實(shí)數(shù)集中冪等，即max(x,x) = x 。 看完上述解釋后，應(yīng)該可以理解GET冪等的含義了。
但在實(shí)際應(yīng)用中，以上2條規(guī)定并沒有這么嚴(yán)格。引用別人文章的例子：比如，新聞?wù)军c(diǎn)的頭版不斷更新。雖然第二次請求會(huì)返回不同的一批新聞，該操作仍然被認(rèn)為是安全的和冪等的，因?yàn)樗偸欠祷禺?dāng)前的新聞。從根本上說，如果目標(biāo)是當(dāng)用戶打開一個(gè)鏈接時(shí)，他可以確信從自身的角度來看沒有改變資源即可。
根據(jù)HTTP規(guī)范，POST表示可能修改變服務(wù)器上的資源的請求 。繼續(xù)引用上面的例子：還是新聞以網(wǎng)站為例，讀者對新聞發(fā)表自己的評論應(yīng)該通過POST實(shí)現(xiàn)，因?yàn)樵谠u論提交后站點(diǎn)的資源已經(jīng)不同了，或者說資源被修改了。
上面大概說了一下HTTP規(guī)范中，GET和POST的一些原理性的問題。但在實(shí)際的做的時(shí)候，很多人卻沒有按照HTTP規(guī)范去做，導(dǎo)致這個(gè)問題的原因有很多，比如說：
1.很多人貪方便，更新資源時(shí)用了GET，因?yàn)橛肞OST必須要到FORM（表單），這樣會(huì)麻煩一點(diǎn)。
2.對資源的增，刪，改，查操作，其實(shí)都可以通過GET/POST完成，不需要用到PUT和DELETE。
3.另外一個(gè)是，早期的但是Web MVC框架設(shè)計(jì)者們并沒有有意識地將URL當(dāng)作抽象的資源來看待和設(shè)計(jì) 。還有一個(gè)較為嚴(yán)重的問題是傳統(tǒng)的Web MVC框架基本上都只支持GET和POST兩種HTTP方法，而不支持PUT和DELETE方法。 轉(zhuǎn)自：http://g21121./blog/1420713
|
