ASP.NET WebAPI前置知識:HTTP與RestfulAPI

對HTTP協議的基本瞭解是能理解並使用RestFul風格API的基礎，在瞭解了這些基礎之後，使用各種RestFul的開發架構才能得心應手。我一開始使用WebApi的時候就因為對這些知識缺乏瞭解，覺得用起來各種不順手，直到熟悉了這些HTTP的知識後，使用WebApi開發起來才覺得得心應手，我的理解裡，RestFul風格的API即是對HTTP協議良好支援，實現HTTP完整語義風格的API。

在介紹這些知識之前，我需要強調一下很多人存在的一個誤區：HTTP的謂詞和資料傳遞方式。絕大多數人接觸並使用的HTTP協議都是在網站編寫的過程中，在一般的WEB應用中，我們僅使用GET、POST兩個謂詞，其他謂詞並不適用，在這一習慣下很多人有幾個奇怪的認知：HTTP協議只適用於網站開發，HTTP僅有兩個謂詞：GET/POST，HTTP調用資料傳遞僅使用表單K-V的形式進行；在這種認知下，用這種風格開發的RestApi經常會不倫不類，使用ASP.NET WebAPi也會顯得不倫不類，平添麻煩。而我們首先要認識到，網站的資料互動只是HTTP使用的一個情境而已，HTTP可以傳遞各種形式的資料。

我們從HTTP的第一行說起：HTTP的第一行包含三個資訊：謂詞、URL、HTTP協議版本。三個資料使用空格隔開。

謂詞：對於RestFul API來說謂詞是非常重要的一個元素，WEB API就是使用謂詞作為預設的路由方式，最常用的謂詞有：POST\DELETE\PUT\GET，這四個謂詞對應了“增、刪、改、查”四個動作（POST和PUT誰是增誰是改不同資料總有不同的說法，我其實有略微有點困惑啦……有定義說PUT是等冪操作，而POST不是，那PUT就更偏重於改而POST更偏重於增）。最常用的謂詞即為這四個，也有其他謂詞擁有不同的語義：

HEAD：僅返回相應頭部，不包含Body

TRACE：對資料轉送過程進行診斷

OPTIONS：請求 Web 服務器告知其支援的各種功能

還有其他謂詞，如果需要可以查詢相關文檔，但並不常用。

其中，GET，DELETE不包含BODY，PUT,POST可以包含BODY。而如果一個謂詞包含了語義之外的操作，例如GET中帶BODY，POST用於刪除資源這種操作也是被允許的，稱之為謂詞的重載，雖然HTTP可以支援謂詞的重載，但並不建議使用，因為不符合標準語義。

URL : URL定義了一個資源，例如www.example.com/person 定義了person為一個資源，結合上面所介紹的謂詞，我們提供Person一組操作：

GET www.example/person/1 即擷取ID為1的使用者的資訊

POST www.example/person/ (BODY中包含Person的描述) 建立一個Person資源

PUT www.example/person/1 (BODY中包含Person的描述) 更新一個Person資源

DELETE www.example/person/1 刪除ID為1的Person資源

HTTP版本：

目前主要使用的是HTTP1.0 和 HTTP1.1協議，HTTP2.0協議正在普及階段，用的還不是很多。HTTP1.0 和HTTP1.1區別很小，其中的差異對於RestFul來說影響並不是很大。具體的差別大家可以查詢相關文檔。

HTTP的第一行內容就是這些，接下來會有一個\r\n來進行換行，接下來就是HTTP HEAD部分，HTTP HEAD描述了HTTP請求和響應。我認為HTTP HEAD即為HTTP協議中最重要的部分，他包含了編碼、BODY長度、內容協商等資訊，你也可以包含一些自訂資訊。下面我來為大家介紹幾個在RestFul API中常用的HEAD:

User-Agent:使用者代理程式，是什麼用戶端發出的請求，如IE、Chrome、Fiddler等

HOST:網域名稱（HOST一般用於伺服器的網站綁定，一般和URL的網域名稱相同，但是在一些自訂的DNS使用方式中，可能會出現HOST和URL中的網域名稱不一致）

Authorization：驗證資訊，這個欄位可以包含一些用於使用者驗證的資訊，而表示方法為：schema authorinfo，中間使用空格隔開，其中schema代表了驗證方法，authorinfo代表了驗證資訊，常見的schema 如 Base：authorinfo使用使用者名稱+密碼，並用Base64進行編碼。或者使用Token，類似於Session的方式。

Accept：接受何種序列化方式返回的資料，用MIME表示，用於對響應資料的內容協商，可以包含多個MIME，按優先順序排列，如application/json，application/xml，text/html；具體伺服器可以返回什麼類型的資料需要由伺服器支援情況而定，有一些標準MIME，可以查到；有時我們也需要一些自訂的MIME，例如bson、protocolbuffer等，我們可以自訂MIME，在服務端開發自己的實現，而這些特的擴充在ASP.NET WebApi中都有相應的擴充點。

Content-Type:使用一個MIME表示，表示所發送請求的Body的序列化方式，常見的如application/json，還有WEB互動最常使用的application/x-www-form-urlencoded，都表示了你的body部分的序列化方式，在請求、響應中都會出現

HTTP HEAD部分我認為是HTTP協議中最核心的部分，其中可配置、使用的地方實在太多太多，而且有太多的細節，以上為我列出的在我的工作中最常用的部分，介紹這些內容的資料全部列出來足夠完成一本書了，大家有興趣可以尋找相關資料，在Rest API中，內容協商經常讓一開始學習使用Rest的人很迷惑，一定要記住Accept，Content-Type兩個頭的作用和區別，Accept表示希望接受什麼樣的資料，Content-Type表示當前請求中Body的編碼方式。在ASP.NET WEBAPI中，如果請求中有Content-Type，而沒有ACCEPT，則預設使用Content-Type中的內容作為響應的內容協商。

響應部分也分為頭部和Body，回應標頭部和要求標頭部最大的不同在於響應首行存在一個HTTP Code，HTTP Code作為API的調用狀態的展示，也很重要，在REST API中最常用的狀態代碼一般為2XX,4XX,5XX三個段，而1XX表示工作還要繼續，3XX一般表示重新導向，在REST API中使用的並不多。而在最常用的三個Status 段中，2XX表示執行成功，4XX表示用戶端資料錯誤(例如參數校正不通過)，5XX表示伺服器端處理錯誤，例如有未處理的異常(如資料庫連接錯誤)，根據這些狀態代碼可以初步判斷API調用的執行狀態。

在首部之後有一個空行（\r\n）接下來就是Content，這裡有具體的業務資料，根據不同的Content-Type使用不同的序列化方式表示，例如JSON，XML，甚至HTML。各位在學習HTTP API時可以認為網頁應用也是HTTP 的一種應用，只是互動方式一般使用application/x-www-form-urlencoded 作為請求、 text/html作為響應的方式進行互動。而RestAPI可以使用其他很多種編碼方式進行互動，支援的更廣，網頁應用只是使用HTTP傳輸的一種應用情境，RestAPI和網頁是可以不分開的。我覺得這一點Nancy比ASP.NET做得更好，Nancy並沒有把RestAPI和網頁割裂開來，而ASP.NET用MVC和WEBAPI將兩者割裂了；請求一個資料，我可以要求Accept為application/json時返回Json資料，而使用text/html時返回一個網頁；當然，將這兩種應用方式切割或合并起來都各有優劣。

我所寫的這些對於HTTP協議而言實在太少太少，大家有興趣的可以自行尋找相關資料，我只是寫出了WEB API中常用的部分，下面我們來用一張圖為大家展示一下這些知識：