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中經常使用的部分，下面咱們來用一張圖爲你們展現一下這些知識：