Http定義了與 服務器的交互方法，其中除了一般我們用的最多的GET,POST 其實還有PUT和DELETE
根據RFC2616標准（現行的HTTP/1.1）其實還有OPTIONS,GET,HEAD,POST,PUT,DELETE,TRACE,CONNECT
簡單地介紹一下吧。
http 的post 和 get 方法確實很多，通俗解釋就是-------
新建一條記錄的話就用post，
更新一條記錄的話就用put.
<POST>
POST 方法被用於請求源服務器接受請求中的實體作為請求資源的一個新的從屬物
POST方法的實際功能是由服務器決定的，並且經常依賴於請求URI（Request-URI）。POST提交的實體是請求URI的從屬物，就好像一個文件從屬於一個目錄，一篇新聞文章從屬於一個新聞組，或者一條記錄從屬於一個數據庫。POST方法執行的動作可能不會對請求URI所指的資源起作用。在這種情況下，200（成功）或者204（沒有內容）將是適合的響應狀態，這依賴於響應是否包含一個描述結果的實體。如果資源被源服務器創建，響應應該是201（Created）並且包含一個實體，此實體描述了請求的狀態。並且引用了這個新資源和一個Location頭域。POST方法的響應是不可緩存的。除非響應里有合適的Cache-Control或者Expires頭域。然而，303（見其他）響應能被用戶代理利用去獲得可緩存的響應。
<PUT>
PUT方法請求服務器去把請求里的實體存儲在請求URI（Request-URI）標識下。
如果請求URI（Request-URI）指定的的資源已經在源服務器上存在，那么此請求里的實體應該被當作是源服務器關於此URI所指定資源實體的最新修改版本。如果請求URI（Request-URI）指定的資源不存在，並且此URI被用戶代理定義為一個新資源，那么源服務器就應該根據請求里的實體創建一個此URI所標識下的資源。如果一個新的資源被創建了，源服務器必須能向用戶代理（user agent） 發送201（已創建）響應。如果已存在的資源被改變了，那么源服務器應該發送200（Ok）或者204（無內容）響應。如果資源不能根據請求URI創建或者改變，一個合適的錯誤響應應該給出以反應問題的性質。實體的接收者不能忽略任何它不理解和不能實現的Content-*（如：Content-Range）頭域，並且必須返回501（沒有被實現）響應。如果請求穿過一個緩存（cache），並且此請求URI（Request-URI）指示了一個或多個當前緩存的實體，那么這些實體應該被看作是舊的。PUT方法的響應是不可緩存的。
POST方法和PUT方法請求最根本的區別是請求URI（Request-URI）的含義不同。POST請求里的URI 指示一個能處理請求實體的資源（譯注：此資源可能是一段程序，如jsp 里的servlet） 。此資源可能是一個數據接收過程，一個網關（gateway，注：網關和代理的區別是：網關可以進行協議轉換，而代理不能，只是起代理的作用，比如緩存服務器其實就是一個代理），或者一個單獨接收注釋的實體。對比而言，PUT方法請求里的URI標識請求里封裝的實體一一用戶代理知道URI 意指什么，並且服務器不能把此請求應用於其它資源（resource）。如果服務器期望請求被應用於一個不同的URI，那么它必須發送301（永久移動）響應；用戶代理可以自己決定是否重定向請求。一個單獨的資源可能會被許多不同的URI指定。如：一篇文章可能會有一個URI指定當前版本，而這個URI區別於這篇文章其它特殊版本的URI。這種情況下，對一個通用URI的PUT請求可能會導致其資源的其它URI請求被源服務器重定義。HTTP/1.1沒有定義PUT方法對源服務器的狀態影響。
等冪方法（Idempotent Mehtods）
方法可以有等冪的性質因為（除了出錯或終止問題）N>0個相同請求的副作用同單個請求的副作用的效果是一樣（譯注：等冪就是值不變性，相同的請求得到相同的響應結果，不會出現相同的請求出現不同的響應結果）。方法GET，HEAD，PUT，DELETE都有這種性質。同樣，方法OPTIONS和TRACE不應該有副作用，因此具有內在的等冪性。然而，有可能有多個請求的請求序列是不等冪的，即使在那樣的序列中所有方法都是等冪的。（如果整個序列整體的執行的結果總是相同的，並且此結果不會因為序列的整體，部分的再次執行而改變，那么此序列是等冪的。）例如，一個序列是非等冪的如果它的結果依賴於一個值，此值在以后相同的序列里會改變。根據定義，一個序列如果沒有副作用，那么此序列是等冪的（假設在資源集上沒有並行的操作）。
相同的請求怎樣處理由我們服務器決定，比如：一個創建一篇博文的uri,被請求兩次時，假如我們的服務器認為他們是不一樣的，那么這時就只能用post，而不能用put.
（注：引用自《超文本傳輸協議-HTTP/1.1（修訂版）
另外一點：
1、PUT: 把消息本體中的消息發送到一個URL,跟POST類似，但不常用。
簡單地說：通常用於向服務器發送請求，如果URI不存在，則要求服務器根據請求創建資源，如果存在，服務器就接受請求內容，並修改URI資源的原始版本。
-----PUT請求那些封裝在Request-URI的實體。如果Request-URI引用一個已存在的資源，則該封裝實體應該作為原始服務器上的修改版本。如果Request-URI不是指向一個已存在的資源，並且該URI可被請求的用戶代碼定義為新資源，則原始服務器可用此URI創建新的資源。如果新的資源被創建，這個原始服務器就必須通過201（Created）響應通知用戶代理。如果已有資源被修改，則發送200或者204響應，表示成功完成了該請求。如果Request-URI既沒有創建也沒有修改資源，則應給予適當的錯誤響應來反映問題本質。實體的接受者不能忽略任何不理解或沒有實現的Content-*（如Content-Range）頭部，並且必須返回501響應。
如果請求經過緩存，並且Request-URI標識出一個或多個當前緩存的實體，則那些實體視為過期了。該方法的響應不會被緩存。
2、POST和PUT的請求根本區別
POST請求的URI表示處理該封閉實體的資源，該資源可能是個數據接收過程、某種協議的網關、或者接收注解的獨立實體。然而，PUT請求中的URI表示請求中封閉的實體-用戶代理知道URI的目標，並且服務器無法將請求應用到其他資源。如果服務器希望該請求應用到另一個URI，就必須發送一個301響應；用戶代理可通過自己的判斷來決定是否轉發該請求。
