RESTful Web 服務四種操做POST/DELETE/PUT/GET

關於REST及RESTful的概念，已有很多文章介紹，這裏整理幾篇我以爲不錯的參考:

• 維基百科的定義: REST
• 什麼是REST跟RESTful? REST理論的中文詳述，其中你能夠了解到WCF Restful屬於RPC 樣式的 Web 服務，ASP.NET Web API屬於RESTful Web 服務。
• 深刻淺出REST InfoQ的專文介紹，文中甚至有Roy T. Fielding當年REST博士論文的中文翻譯連接。另外值得一提的，你們可能沒聽過Roy Fielding的大名，但若是得知他是HTTP規格的主要做者及Apache HTTP Server項目的發起人之一，應該不會有人懷疑他在Web技術領域的份量。

上面的文章建議你們認真的讀一下，這裏咱們簡要的介紹下REST 作入門介紹，理解整個 REST 能讓咱們在 ASP.NET Web API 的路上更順暢。

REST是什麼？

REST ( REpresentational State Transfer )，State Transfer 爲 "狀態傳輸" 或 "狀態轉移 "，Representational 中文有人翻譯爲"表徵"、"具象"，合起來就是 "表徵狀態傳輸" 或 "具象狀態傳輸" 或 "表述性狀態轉移"，不過，通常文章或技術文件都比較不會使用翻譯後的中文來撰寫，而是直接引用 REST 或 RESTful 來表明，由於 REST 一整個觀念，想要只用六個中文字來完整表達真有難度。

REST 一詞的出於《Architectural Styles and 
the Design of Network-based Software Architectures》論文，咱們先簡單從標題來看，它應該是一種架構樣式 (Architectural Styles) 與軟件架構 (Software Architectures)，並且是以網絡 (Network-based) 爲基礎，重點就是：

• 架構樣式 (Architectural Styles)
• 軟件架構 (Software Architectures)
• 網絡 (Network-based) 爲基礎

REST 自己是設計風格而不是標準。REST 談論一件很是重要的事，如何正確地使用 Web標準，例如，HTTP 和 URI。想要了解 REST 最好的方式就是思索與瞭解 Web 及其工做方式。若是你設計的應用程序能符合 REST 原則 (REST principles)，這些符合 REST 原則的 REST 服務可稱爲 "RESTful web service" 也稱 "RESTful Web API"。"-ful" 字尾強調它們的設計徹底符合 REST 論文裏的建議內容。

資源 RESOURCE

在 REST 中的資源 (Resource) 表明整個網絡上的資源。網絡上提供了各式各樣的資源，而網絡上的資源由 URI (統一資源標識符,Uniform Resource Identifier) 來提供。 
回想，你如何連上個人 博客，你可能經過瀏覽器直接輸入  www.cnblogs.com/shanyou 此域名來到達首頁，也能用書籤或網絡上的連接，經點擊後來連上個人博客。而後，你想看這一篇名爲「REST 入門介紹」的文章，因此以你接下去點擊這文章的標題連結，接去下閱讀。咱們簡易瞭解一下整個流程：

1. 經過URL ( http://www.cnblogs.com/shanyou ) ， Client 向 http://www.cnblogs.com/shanyou 發出請求
2. www.cnblogs.com/shanyou 收到請求，迴應首頁給 Client
3. Client 又點擊 REST 文章連結  (假設是 http://www.cnblogs.com/shanyou/archive/2011/06/30/2095018.html) 向 http://www.cnblogs.com/shanyou發出archive/2011/06/30/2095018.html  此篇文章的請求
4. www.cnblogs.com/shanyou  收到請求，響應 REST 文章內容給 Client

Client 的經過 URI 來獲取資源的具體象徵 (Representational)。Client 取得這些具體象徵使這些應用程序轉變其狀態 (以 瀏覽器而言，取得 HTML、CSS、JavaScript … 來生成界面)，隨着不斷取得資源的具體象徵， Client 端不斷地改變其狀態，這樣不斷的反覆 (iterations ) 過程就是所謂的 Representational State Transfer。

使用 WEB 標準

上述是最接近平常的範例，這些行爲在 HTTP 規範中稱之爲 GET，也就是經過URL 來 GET 我想要的資源。另外一經常使用的例子是填寫表單，例如，登入表單，我想進行登入動做，就必須先發送帳號與密碼給某一資源，此資源會驗證你所傳送的數據是否正確，再進行後續動做。咱們發送信息給資源的行爲在 HTTP 規範中稱之爲 POST。 
在 HTTP/1.1 RFC 2616第 5.1.1 Method 一節定義了八大類 HTTP 方法，除了咱們經常使用的 GET 與 POST 以外，在 REST 中經常使用的還有 PUT 與 DELETE。此 GET, POST, PUT, DELETE 正好能夠對應咱們 CRUD (Create, Read, Update, Delete) 四種數據操做。

HTTP Method 與 CURD 數據處理操做對應
HTTP方法	數據處理	說明
POST	Create	新增一個沒有id的資源
GET	Read	取得一個資源
PUT	Update	更新一個資源。或新增一個含 id 資源(若是 id 不存在)
DELETE	Delete	刪除一個資源

RESTFUL WEB SERVICE

RESTful Web Service (又稱 RESTful Web API) 是一個使用 HTTP 並符合 REST 原則的 Web 服務。咱們知道，經過 URL 能夠傳送 GET 請求，在 表單指定 method="GET|POST" 來送出請求。但咱們要處理 PUT 或 DELETE 的請求呢？經過 RESTful 咱們能夠簡單 URI 來定義資源並和 HTTP 方法配合使用。

Resource 與 HTTP 方法的對應
資源	資源說明	GET	PUT	POST	DELETE
http://www.cnblogs.com/Products/	Products是一組資源集合	列出 該組資源集合中每一個資源的詳細信息	更新 當前整組資源	新增 或附加一個新資源。該操做傳回新資源的URL	刪除 整組資源
http://www.cnblogs.com/Products/1	Products/1是單個資源	取得 指定的資源的詳細信息	更新 或新增指定的資源	新增 或附加一個新元素	刪除 指定的元素

以上表格有沒有很像咱們通常在對數據庫表格的操做順序，進入一個 Table 的數據首頁 (一般是列表)，此頁面會有「新增、更新、刪除、詳細」等連結，你想進行什麼操做，就點那一個連結。 
在 RESTful 每一個資源有本身獨立的 URI， Client 從資源集合或單個資源開始進入，無論是資源集合或單個資源，咱們都能與 HTTP 方法配合使用，例如，GET 下載，PUT 更新，POST 新增，DELETE 刪除。

ASP.NET Web API 是一個框架(framework)，能讓你在 .NET Framwork 之上架設 HTTP 服務 (HTTP Services)。ASP.NET Web API 是 .NET Framework 上構建RESTful 應用程序的理想平臺。

在 Julie Lerman's 的 How I see Web API 一文中，用了一張圖來簡明說明 Web API：

An Introduction to ASP.NET Web API

 

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方式容易被人肉眼看到，或者出如今歷史紀錄裏，仍是可能被肉眼看到，都是一些本地的問題。