REST似乎在一夜間興起了檀葛,這可能引起一些爭議,反對者可以說REST是WEB誕生之始甚而是HTTP出現(xiàn)之日就相伴而生的原則。但是毋庸置疑的事實是,在Google和Yahoo等網(wǎng)絡(luò)巨頭發(fā)布的相同功能的Web Service API中凤类,REST無疑受到更多的青睞,因此是不是可以這樣說:RPC在一夜之間衰落了普气?
在一篇作業(yè)的小文章里討論整套RPC的原理谜疤,無疑太過龐大了,況且RPC在Web Service領(lǐng)域的應(yīng)用也無過XML-RPC以及由此延伸的SOAP而已现诀。在原理上唯一重要的夷磕,是傳統(tǒng)程序的函數(shù)調(diào)用和返回在RPC中被請求和應(yīng)答代替了而已。既然如此仔沿,在討論REST之前先闡述SOAP坐桩,可能是合乎邏輯的順序。
什么是SOAP?
SOAP (Simple Object Access Protocol) 顧名思義于未,是一個嚴格定義的信息交換協(xié)議撕攒,用于在Web Service中把遠程調(diào)用和返回封裝成機器可讀的格式化數(shù)據(jù)陡鹃。事實上SOAP數(shù)據(jù)使用XML數(shù)據(jù)格式烘浦,定義了一整套復(fù)雜的標簽,以描述調(diào)用的遠程過程萍鲸、參數(shù)闷叉、返回值和出錯信息等等。而且隨著需要的增長脊阴,又不得增加協(xié)議以支持安全性握侧,這使SOAP變得異常龐大,背離了簡單的初衷嘿期。另一方面品擎,各個服務(wù)器都可以基于這個協(xié)議推出自己的API,即使它們提供的服務(wù)及其相似备徐,定義的API也不盡相同萄传,這又導致了WSDL的誕生。WSDL (Web Service Description Language) 也遵循XML格式蜜猾,用來描述哪個服務(wù)器提供什么服務(wù)秀菱,怎樣找到它,以及該服務(wù)使用怎樣的接口規(guī)范蹭睡,簡言之衍菱,服務(wù)發(fā)現(xiàn)。現(xiàn)在肩豁,使用Web Service的過程變成脊串,獲得該服務(wù)的WSDL描述辫呻,根據(jù)WSDL構(gòu)造一條格式化的SOAP請求發(fā)送給服務(wù)器,然后接收一條同樣SOAP格式的應(yīng)答琼锋,最后根據(jù)先前的WSDL解碼數(shù)據(jù)印屁。絕大多數(shù)情況下,請求和應(yīng)答使用HTTP協(xié)議傳輸斩例,那么發(fā)送請求就使用HTTP的POST方法雄人。
什么是REST?
REST (REpresentational State Transfort) 形式上應(yīng)該表述為客戶端通過申請資源來實現(xiàn)狀態(tài)的轉(zhuǎn)換念赶,在這個角度系統(tǒng)可以看成一臺虛擬的狀態(tài)機础钠。拋開R. T. Fielding博士論文里晦澀的理論不說,REST應(yīng)該滿足這樣的特點:
1)客戶端和服務(wù)器結(jié)構(gòu)叉谜;
2)連接協(xié)議具有無狀態(tài)性旗吁;
3)能夠利用Cache機制增進性能;
4)層次化的系統(tǒng)停局;
5)按需代碼很钓。
說到底,REST只是一種架構(gòu)風格董栽,而不是協(xié)議或標準码倦。但這種新的風格(也許已經(jīng)歷史悠久?)對現(xiàn)有的以SOAP為代表的Web Service造成的沖擊也是革命性的锭碳,因為它面向資源袁稽,甚至連服務(wù)也抽象成資源,因為它和HTTP緊密結(jié)合擒抛,因為它服務(wù)器無狀態(tài)推汽。
REST與SOAP的區(qū)別
因為SOAP并不假定傳輸數(shù)據(jù)的下層協(xié)議,因此必須設(shè)計為能在各種協(xié)議上運行歧沪。即使絕大多數(shù)SOAP是運行在HTTP上歹撒,使用URI標識服務(wù),SOAP也僅僅使用POST方法發(fā)送請求诊胞,用一個唯一的URI標識服務(wù)的入口暖夭。
舉一個圖書館在線查詢管理系統(tǒng)為例,服務(wù)提供者必須為每一本書提供一個內(nèi)部標識厢钧,然后可能定義一個listBooks操作來返回一系列圖書鳞尔,一個getBook操作來返回指定的圖書,一個createBook操作來向數(shù)據(jù)庫加入新增的圖書早直,一個deleteBook操作來刪除作廢的圖書寥假,每個操作都有各自的參數(shù),尤其是用內(nèi)部標識來標識操作的圖書霞扬。這種設(shè)計被詬病之處糕韧,在于deleteBook操作也要用POST方法來發(fā)送枫振,而其實HTTP協(xié)議有更和邏輯的DELETE方法可用。REST正是這樣設(shè)計的萤彩,REST為每一個資源(此處是圖書)指定一個唯一的URI粪滤,而用HTTP的4種方法GET、POST雀扶、PUT杖小、DELETE直觀地表示獲取、創(chuàng)建愚墓、更新和刪除圖書予权。同時圖書集合也是和單本的圖書不同的資源,如果用/books來代表圖書列表浪册,/books/ID來代表標識為ID的圖書扫腺,那么對/books的GET操作就代表返回整個圖書列表,對/books/ID的DELETE操作代表刪除指定的圖書村象,等等笆环。
REST的優(yōu)點
REST簡單而直觀,把HTTP協(xié)議利用到了極限厚者,在這種思想指導下躁劣,它甚至用HTTP請求的頭信息來指明資源的表示形式(如果一個資源有多種形式的話,例如人類友善的頁面還是機器可讀的數(shù)據(jù)籍救?)习绢,用HTTP的錯誤機制來返回訪問資源的錯誤。由此帶來的直接好處是構(gòu)建的成本減少了蝙昙,例如用URI定位每一個資源可以利用通用成熟的技術(shù),而不用再在服務(wù)器端開發(fā)一套資源訪問機制梧却。又如只需簡單配置服務(wù)器就能規(guī)定資源的訪問權(quán)限奇颠,例如通過禁止非GET訪問把資源設(shè)成只讀。
服務(wù)器無狀態(tài)帶來了更多額外好處放航,因為每次請求都包含響應(yīng)需要的所有信息烈拒,所有狀態(tài)信息都存儲在客戶端,服務(wù)器的內(nèi)存從龐大的狀態(tài)信息中解放出來广鳍。而且現(xiàn)在即使一臺服務(wù)器突然死機對客戶的影響也微乎其微荆几,因為另一臺服務(wù)器可以馬上代替它的位置,而不需要考慮恢復(fù)狀態(tài)信息赊时。更多的緩存也變成可能吨铸,而之前由于服務(wù)器有狀態(tài),對同一個URI的請求可能導致完全不同的響應(yīng)祖秒。
總體結(jié)果是诞吱,網(wǎng)絡(luò)的容錯性和延展性都增強了舟奠,這些本來是WEB設(shè)計的初衷,日趨復(fù)雜和定制的WEB把它們破壞了房维,現(xiàn)在REST又返璞歸真沼瘫,試圖把Web Service帶回簡單的原則中來。
REST是萬能的嗎咙俩?
但是REST就是萬能的嗎耿戚?無狀態(tài)帶來了巨大的優(yōu)勢,同時也帶來了難以解決的問題阿趁,例如溅话,怎樣授權(quán)特定用戶才能使用的服務(wù)?怎樣驗證用戶身份歌焦?如果堅持服務(wù)器無狀態(tài)飞几,也就是不記錄用戶登錄狀態(tài),勢必要求每一次服務(wù)請求都包含完整的用戶身份和驗證信息独撇。在這種情況下屑墨,怎樣避免冒認?怎樣避免用戶信息泄漏纷铣?事實上卵史,構(gòu)建REST附屬的安全機制已經(jīng)在討論中,其結(jié)果無非導致另一個SOAP:復(fù)雜的需求摧殘了易用性搜立。
REST的支持者聲稱REST的請求和應(yīng)答數(shù)據(jù)簡單可讀以躯,而SOAP則需要一系列繁瑣的封裝;即使如此啄踊,SOAP仍然不能達到接口的一致性忧设,不同的廠商有各自的接口,而REST只使用HTTP定義的方法颠通,因此是通用的址晕。事實確實如此嗎?試想用REST實現(xiàn)兩數(shù)求和的服務(wù)顿锰,如果按照建議的做法谨垃,把服務(wù)(此處是加法)作為一個資源,參數(shù)(此處是兩個加數(shù))作為請求的參數(shù)硼控,結(jié)果以XML或JSON語法返回刘陶,是否比SOAP更簡單易用?通用接口仍然沒法達到牢撼,因為資源的名稱匙隔、參數(shù)的名稱、結(jié)果的格式仍然是服務(wù)提供者定義的浪默。
為了解決這個問題牡直,提出了WASL(Web Application Description Language)來描述REST接口缀匕。WADL就像是WSDL的REST版,隨著REST被應(yīng)用到復(fù)雜的領(lǐng)域碰逸,SOAP的影子無處不在乡小。
面向資源和面向事務(wù)(非常明顯的說明了Rest的試用范圍,請求地圖數(shù)據(jù)就可以認為主要是請求一種特殊的資源)
REST在面向資源的應(yīng)用中左右逢源饵史,但在面向事務(wù)的應(yīng)用中卻未如人意满钟。面向資源的應(yīng)用操作簡單,無非創(chuàng)建胳喷、讀取湃番、改變、刪除幾項吭露,但是面向事務(wù)的應(yīng)用不允許用戶直接操作資源吠撮,用戶只需向系統(tǒng)提交一個事務(wù)說明要求,然后等待事務(wù)的完成讲竿,就如一個網(wǎng)上銀行的用戶不直接修改賬戶和存款泥兰,而是提交一個事務(wù)告訴銀行自己要轉(zhuǎn)賬。如果把這樣的服務(wù)看成一種資源题禀,通過向資源發(fā)送POST請求完成事務(wù)鞋诗,那不過是SOAP的翻版而已,無論是這樣迈嘹,還是通過PUT來創(chuàng)建事務(wù)削彬,都改變了系統(tǒng)的狀態(tài)(資源本身未改變,此處是改變了用戶的余額)秀仲,顯然違背了REST直觀的初衷融痛。
事實上,一些Web Service提供者提供的REST API只有REST的外殼啄育,傳輸?shù)恼埱蠛蛻?yīng)答全然是簡化了的SOAP酌心,這種新瓶裝舊酒的做法只是加深了標準的分歧而已。歸根結(jié)底REST無法簡單地解決一些應(yīng)用挑豌,因此我們只能看到SOAP在REST外殼下的借尸還魂。沒有一項技術(shù)能一勞永逸地解決所有問題墩崩,只需要在預(yù)定的約束下優(yōu)美地解決所在領(lǐng)域的問題就足夠了氓英。一項新技術(shù)推出的時候總是引來無數(shù)的跟風和吹捧,只有當塵埃落定之后才能得到中肯的評價鹦筹。