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響應；使用者代理可通過自己的判斷來決定是否轉發該請求。