|
REST不是一個標(biāo)準(zhǔn)，而是一種軟件應(yīng)用架構(gòu)風(fēng)格?；赟OAP的Web服務(wù)采用RPC架構(gòu)，如果說RPC是一種面向操作的架構(gòu)風(fēng)格，而REST則是一種面向資源的架構(gòu)風(fēng)格。REST是目前業(yè)界更為推崇的構(gòu)建新一代Web服務(wù)（或者Web API）的架構(gòu)風(fēng)格。由于REST僅僅是一種價(jià)格風(fēng)格，所以它是與具體的技術(shù)平臺無關(guān)的，也就是說采用REST架構(gòu)的應(yīng)用未必一定建立在Web之上，所以在正式介紹REST之前，我們先來簡單認(rèn)識一下Web。
如果要問大家這樣一個問題：“在過去半個世紀(jì)中，哪種信息技術(shù)對人類的影響最為深遠(yuǎn)？”，我想很多人的答案是Web（World Wide Web、WWW、W3或者萬維網(wǎng)），因?yàn)樗淖兞宋覀兊纳罘绞胶退季S方式。如果各位閱讀過W3C介紹WWW的官方文檔（“http://www./WWW/”），應(yīng)該對它的第一句話記憶猶新——“The World Wide Web (known as "WWW', "Web" or "W3") is the universe of network-accessible information, the embodiment of human knowledge”。如果將這句話翻譯成簡潔的中文，就是“Web是（網(wǎng)絡(luò)）信息的來源，知識的化身”。 Web為我們提供了一種利用HTTP協(xié)議獲取和操作網(wǎng)絡(luò)資源的方式，這些將Web服務(wù)器作為宿主的資源不僅僅包含像文字和圖片這些傳統(tǒng)的信息載體，還包含音頻和視頻這些多媒體信息。Web的核心主要體現(xiàn)在三個方面，即HTTP、超文本（Hypertext）和超媒體（Hypermedia）[1]，超文本和超媒體規(guī)范了網(wǎng)絡(luò)信息的表現(xiàn)形式，而HTTP則提供了網(wǎng)絡(luò)訪問的標(biāo)準(zhǔn)協(xié)議。接下來我們就以圍繞著HTTP對Web作一下基本的介紹。 一、TCP/IP與HTTP TCP/IP是以IP和TCP協(xié)議為核心的一整套網(wǎng)絡(luò)協(xié)議的總稱，所以有時候我們也稱其為TCP/IP協(xié)議簇。毫不夸張地說，TCP/IP支撐著整個互聯(lián)網(wǎng)，因?yàn)樗褪腔ヂ?lián)網(wǎng)采用的網(wǎng)絡(luò)協(xié)議。TCP/IP協(xié)議簇劃分為如右圖所示的4個層次[2]（應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和鏈路層），構(gòu)成整個協(xié)議簇的各個子協(xié)議處于相應(yīng)層次中。 既然將整個協(xié)議簇命名為TCP/IP，那么IP和TCP自然就是其中最為核心的兩個協(xié)議了。處于網(wǎng)絡(luò)層的IP協(xié)議提供的IP數(shù)據(jù)報(bào)傳輸是不可靠的，因?yàn)樗怀兄Z盡可能地將數(shù)據(jù)報(bào)發(fā)送出去，但不能保證發(fā)送的數(shù)據(jù)報(bào)能夠成功地抵達(dá)目的地。IP協(xié)議的不可靠性還體現(xiàn)在它不能檢測數(shù)據(jù)在傳輸過程中是否發(fā)生了改變，也就是說數(shù)據(jù)的完整性得不到保證。IP協(xié)議是一個無連接（Connectionless）的網(wǎng)絡(luò)協(xié)議，每次數(shù)據(jù)報(bào)的處理對它來說均是獨(dú)立的，因此IP協(xié)議也不能提供針對有序傳輸（數(shù)據(jù)接收的順序與發(fā)送的順序一致）的保證。 雖然IP協(xié)議只能提供不可靠的數(shù)據(jù)傳輸，同時有序傳輸也得不到保證，但是建立在它之上的傳輸層協(xié)議TCP有效地解決了這兩個問題。TCP是一個基于連接的協(xié)議，數(shù)據(jù)交換雙方在進(jìn)行報(bào)文傳輸之前需要建立連接，報(bào)文傳輸結(jié)束之后需要關(guān)閉連接。這是一個雙工（Duplex）連接，數(shù)據(jù)交換的雙工均可以利用它向?qū)Ψ桨l(fā)送數(shù)據(jù)。 TCP利用“接收確認(rèn)”和“超時重傳”機(jī)制確保了數(shù)據(jù)能夠成功抵達(dá)目的地。具體來說，接收方在成功接收到數(shù)據(jù)之后會回復(fù)一個確認(rèn)消息。發(fā)送方在本地具有一個存放尚未得到確認(rèn)的已發(fā)消息的緩沖區(qū)，如果發(fā)送方在一個設(shè)定的時限內(nèi)沒有接收到針對某個已發(fā)報(bào)文的確認(rèn)消息，它會從該緩存區(qū)中選擇對應(yīng)的報(bào)文進(jìn)行重新發(fā)送。在接收到確認(rèn)之后，相應(yīng)的報(bào)文會從緩存區(qū)中移除。 為了解決有序傳輸?shù)膯栴}，發(fā)送方會為每個報(bào)文進(jìn)行編號，報(bào)文的序號體現(xiàn)了它們被發(fā)送的順序。接收端在接收到某個報(bào)文之后，它會利用此序號判斷是否具有尚未成功接收的已發(fā)報(bào)文，如果有的話，該報(bào)文會被存放到本地的緩沖區(qū)中。等到之前發(fā)送的報(bào)文全部被接收之后，接收方按照序號對接收的報(bào)文依次向上（應(yīng)用層）遞交，成功遞交的報(bào)文會被從緩存區(qū)中移除。除了接收到“失序”的報(bào)文之外，接收方還有可能接收到重復(fù)的報(bào)文，因?yàn)闆]有報(bào)文均具有一個唯一的序號，如果該序號小于已經(jīng)成功遞交或者添加到緩存區(qū)中的報(bào)文序號，它會被認(rèn)為是重復(fù)接收的報(bào)文而被丟棄。 由于每個TCP報(bào)文段都具有一個16位的檢驗(yàn)和（Checksum），所以接收方可以根據(jù)它確認(rèn)數(shù)據(jù)在傳輸過程中是否被篡改。除此之外，TCP還提供了“流量控制”功能避免了雙方因緩存區(qū)大小不一致而導(dǎo)致報(bào)文丟失。具體來說，如果發(fā)送方的緩沖區(qū)大于接收方的緩存區(qū)，會導(dǎo)致接收方在緩沖區(qū)已滿的情況下無法處理后續(xù)接收的報(bào)文，所以接收方會將自己緩存區(qū)剩余的大小及時通知給發(fā)送端，后者據(jù)此控制報(bào)文發(fā)送“流量”。 HTTP（Hypertext Transfer Protocol），全稱為“超文本傳輸協(xié)議”，是TCP/IP協(xié)議簇的一部分。從圖1-1可以看出，這是一個位于應(yīng)用層的網(wǎng)絡(luò)協(xié)議，在它之下的就是TCP協(xié)議。由于TCP協(xié)議是一個“可靠”的協(xié)議，HTTP自然也能提供可靠數(shù)據(jù)傳輸功能。 IP協(xié)議利用IP地址來定位數(shù)據(jù)報(bào)發(fā)送的目的地，而利用域名系統(tǒng)（DNS）可以實(shí)現(xiàn)域名與IP地址之間的轉(zhuǎn)換。TCP協(xié)議利用端口號標(biāo)識應(yīng)用程序，所以某個應(yīng)用程序在使用TCP協(xié)議進(jìn)行通信的時候必須指定目標(biāo)應(yīng)用的IP地址（或者域名）和端口號。HTTP默認(rèn)采用的端口號為80，而HTTPS（利用TLS/SSL為HTTP提供傳輸安全保障）的默認(rèn)端口號則為443，當(dāng)然在網(wǎng)絡(luò)可達(dá)的前提下，我們可以指定任意的端口。 二、Web資源這里所說的資源是一個寬泛的概念，任何寄宿于Web服務(wù)器可以利用HTTP協(xié)議獲取或者操作的“事物”均可以稱為資源。這也是一個抽象的概念，不僅僅是寄宿于Web服務(wù)器的某個靜態(tài)物理文件可以視為Web資源，通過Web應(yīng)用根據(jù)請求動態(tài)生成的數(shù)據(jù)也是Web資源。 媒體類型資源實(shí)際上是一種承載著某種信息的數(shù)據(jù)，相同的信息可以采用不同形態(tài)的數(shù)據(jù)來展現(xiàn)，數(shù)據(jù)的“形態(tài)”主要體現(xiàn)為展示數(shù)據(jù)所采用的格式，比如一個數(shù)據(jù)對象可以通過XML格式來表示，也可以通過JSON格式來表示。數(shù)據(jù)的處理必須依賴于一種已知的格式，所以將Web資源的形態(tài)以一種標(biāo)準(zhǔn)化的方式固定下來顯得尤為重要，這就是我們接下來著重介紹的媒體媒體（Media Type）。 不論是通過HTTP請求從Web服務(wù)器上獲取資源，還是利用請求向服務(wù)器提交資源，響應(yīng)或者請求的主體（Body）除了包含承載資源本身的數(shù)據(jù)之外，其報(bào)頭（Header）部分還應(yīng)該包含表示數(shù)據(jù)形態(tài)的媒體類型。 媒體類型又被稱為MIME（Multipurpose Internet Mail Extension）類型，MIME是一個互聯(lián)網(wǎng)標(biāo)準(zhǔn)，它擴(kuò)展了電子郵件標(biāo)準(zhǔn)，使其能夠支持非ASCII字符、二進(jìn)制格式附件等多種格式的郵件消息。由于MIME在電子郵件系統(tǒng)應(yīng)用得非常好，所以被HTTP用于描述并標(biāo)記多媒體內(nèi)容。下面的列表給出了一種常用的媒體類型。
URI、URL和URN可操作的Web資源應(yīng)該具有一個 唯一的標(biāo)識。雖然具有很多唯一性標(biāo)志符的種類可供選擇（比如GUID），但是采用URI來標(biāo)識Web資源已經(jīng)成為了一種共識，實(shí)際上URI的全稱為“統(tǒng)一資源標(biāo)志符（Uniform Resource Identifier）”。 我想有很多人弄不清楚URI和URL之間的區(qū)別，有人甚至覺得這是同一概念的不同表述而已。一個URL肯定是一個URI，但是一個URI并不一定是一個URL，URL僅僅是URI的一種表現(xiàn)形式而已。兩者的差異其實(shí)可以直接從其命名來區(qū)分，URI是Web資源的標(biāo)志符，所以只要求它具有“標(biāo)識性”即可；URL全稱為“統(tǒng)一資源定位符（Uniform Resource Locator）”，所以除了標(biāo)識性之外，它還具有定位的功能，用于描述Web資源所在的位置。 URL不僅僅用于定位目標(biāo)資源所在的位置，還指名了獲取資源所采用的協(xié)議，一個完整的URL包含協(xié)議名稱、主機(jī)名稱（IP地址或者域名）、端口號、路徑和查詢字符串5個部分。比如對于“ http://www.:8080/images/photo.png?size=small”這樣一個URL，上述的5個部分分別是“http”、“www.”、“8080”、“/images/photo.png”和“?size=small”。 除了URL，URN也是URI的一種表現(xiàn)形式，URN全稱“統(tǒng)一資源定位符（Uniform Resource Name）”。URN與資源所在的位置無關(guān)，倘若采用URN來唯一標(biāo)識某個資源，在位置發(fā)生改變的時候標(biāo)志符依然可以保持不變。URN一般也不會涉及到獲取被標(biāo)識資源采用的網(wǎng)絡(luò)協(xié)議，所以不需要為利用不同協(xié)議訪問的相同資源定義不同的標(biāo)志符。 三、HTTP事務(wù)雖然TCP是一種基于連接的傳輸層協(xié)議，并且保存雙方針對同一個連接的多輪消息交換的會話狀態(tài)，但是建立其上的HTTP則是一種無狀態(tài)的網(wǎng)絡(luò)協(xié)議。HTTP采用簡單的“請求/響應(yīng)”消息交換模式，一次HTTP事務(wù)（Transaction）始于請求的發(fā)送，止于響應(yīng)的接收。針對客戶端和Web服務(wù)器的多次消息交換來說，每個HTTP事務(wù)均是相互獨(dú)立的。 HTTP方法HTTP采用簡單的請求/響應(yīng)模式的消息交換旨在實(shí)現(xiàn)針對某個Web資源的某種操作。至于針對資源的操作類型，不外乎CRUD（Create、Retrieve、Update和Delete）而已。一個HTTP請求除了利用URI標(biāo)志目標(biāo)資源之外，還需要通過HTTP方法（HTTP Method或者HTTP Verb）指名針對資源的操作類型。我們常用的HTTP方法 包括GET、POST、PUT、DELETE、HEAD、OPTIONS、TRACE、CONNECTION和PATCH等，我們將在《設(shè)計(jì)篇》以REST的視角來對它們進(jìn)行詳細(xì)介紹。 響應(yīng)狀態(tài)碼針對客戶端向Web服務(wù)器發(fā)送的任意一個HTTP請求，不論在何種情況下得到一個響應(yīng)，每個響應(yīng)均具有一個由3位數(shù)字表示的狀態(tài)碼和相應(yīng)的描述文字。不同數(shù)值的狀態(tài)碼體現(xiàn)了不同類型的響應(yīng)狀態(tài)，W3C對響應(yīng)狀態(tài)碼的范圍作了如下的規(guī)范。
四、HTTP報(bào)文客戶端和Web服務(wù)器在一次HTTP事務(wù)中交換的消息被稱為HTTP報(bào)頭，客戶端發(fā)送給服務(wù)器的請求消息被稱為請求報(bào)文，服務(wù)器返回給客戶端的響應(yīng)消息被稱為響應(yīng)報(bào)頭。請求報(bào)文和響應(yīng)報(bào)頭采用純文本編碼，由一行行簡單的字符串組成。一個完整的HTTP報(bào)文由如下三個部分構(gòu)成。
接下來我們看看一個具體HTTP報(bào)文具有怎樣的結(jié)構(gòu)。下面這個文本片段反映的是我們通過Chrome瀏覽器訪問微軟的官網(wǎng)（www.microsoft. com）對應(yīng)的HTTP請求，起始行體現(xiàn)了HTTP請求的三個基本屬性，即HTTP方法（GET）、目標(biāo)資源（http://www.microsoft.com/en-us/default.aspx）和協(xié)議版本（HTTP/1.1）。 1: GET http://www.microsoft.com/en-us/default.aspx HTTP/1.1
2: Host: www.microsoft.com
3: Connection: keep-alive
4: Cache-Control: max-age=0
5: User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
6: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
7: Accept-Encoding: gzip,deflate,sdch
8: Accept-Language: en-US,en;q=0.8
9: Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
10: Cookie: ...
上述這個請求報(bào)文不具有主體，所以起始行之外的所有內(nèi)容均為報(bào)頭集合，我們們可以根據(jù)這些報(bào)頭獲得主機(jī)名稱、采用的緩存策略、瀏覽器相關(guān)信息、以及客戶端支持的媒體類型（Media Type）、編碼方式、語言和字符集等。 前面的HTTP請求通過瀏覽器發(fā)送給服務(wù)端之后會接收到具有如下結(jié)構(gòu)的響應(yīng)報(bào)文，我們可以此從它的起始行得到采用的HTTP版本（HTTP/1.1）和響應(yīng)狀態(tài)碼（“200 OK”，表示請求被正常接收處理）。響應(yīng)的內(nèi)容被封裝到響應(yīng)報(bào)文的主體部分，其媒體類型的通過報(bào)頭“Content-Type”表示。由于該響應(yīng)報(bào)文的主體內(nèi)容是一個HTML文檔，所以“Content-Type”報(bào)頭表示的媒體類型為“text/html”。 1: HTTP/1.1 200 OK
2: Cache-Control: no-cache
3: Pragma: no-cache
4: Content-Type: text/html; charset=utf-8
5: Content-Encoding: gzip
6: Expires: -1
7: Vary: Accept-Encoding
8: Server: Microsoft-IIS/7.5
9: X-AspNet-Version: 2.0.50727
10: VTag: 791897542300000000
11: P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
12: X-Powered-By: ASP.NET
13: Date: Wed, 18 Jan 2012 07:06:25 GMT
14: Content-Length: 34237
15:
16: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www./TR/xhtml1/DTD/xhtml1-transitional.dtd"> 17: <html>…</html> [1]超文本/超媒體（HyperText/HyperMedia）：超文本是一份呈現(xiàn)文本內(nèi)容的電子文檔，其核心在于可以利用內(nèi)嵌的“超鏈接（Hyperlink）”直接訪問引用的另一份文檔。超媒體對超文本作了簡單的擴(kuò)展以呈現(xiàn)多媒體內(nèi)容（比如圖片、音頻和視頻等）。HTML文檔是我們常見的最為典型的超文本/超媒體文件。 [2] 除了采用這種4個層次的劃分方法之外，還具有另外兩種典型的劃分方式。其中一種在鏈路層下面添加一個基于物理網(wǎng)絡(luò)硬件的物理層，這種劃分方法與此沒有本質(zhì)的區(qū)別。另外一種則是將TCP/IP協(xié)議簇劃分為包括應(yīng)用層、表示層、會話層、傳輸層、網(wǎng)絡(luò)層、鏈路層和物理層在內(nèi)的7個層次。 參考資料： 我所理解的RESTful Web API [Web標(biāo)準(zhǔn)篇]
|
|
|
