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

BODY包含Person的描述) 建立一個Person資源

         PUT www.example/person/1

(BODY包含Person的描述)

更新#一個Person資源          DELETE www.example/person/1 刪除ID為1的Person資源

        

    . 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、Fid dler等

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

         Authorization：驗證訊息，而這個欄位可以包含一些用於使用者驗證的訊息，而表示方法為：schema authorinfo，中間使用空格隔開，其中schema代表了驗證，其中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中的內容作為回應的內容協商。

       Sharp狀態

的展示，也很重要，在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中常用的部分，下面我們來用一張圖為大家展示一下這些知識：

以上是ASP.NET WebAPI前知識:HTTP與RestfulAPI的詳細內容。更多資訊請關注PHP中文網其他相關文章！