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