ASP.NET WebAPI前知識:HTTP與RestfulAPI

PHPz
發布: 2017-04-04 15:51:05
原創
2780 人瀏覽過

         對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中文網其他相關文章!

相關標籤:
來源:php.cn
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
最新問題
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板
關於我們 免責聲明 Sitemap
PHP中文網:公益線上PHP培訓,幫助PHP學習者快速成長!