REST技術(shù)詳解.doc

REST和SOAP的“風(fēng)格”比較REST和SOAP的“風(fēng)格” 架構(gòu)風(fēng)格：來自Roy Thomas Fielding博士的定義：一種架構(gòu)風(fēng)格是一組協(xié)作的架構(gòu)約束，這些約束限制了架構(gòu)元素的角色和功能，以及在任何一個(gè)遵循該風(fēng)格的架構(gòu)中允許存在的元素之間的關(guān)系。SOAP：簡(jiǎn)單對(duì)象訪問協(xié)議，基于XML，是一種應(yīng)用協(xié)議，可以跨多種傳輸協(xié)議來傳遞消息（比如HTTP、SMTP），Soap是針對(duì)RPC的解決方案。其初衷是作為一種輕量級(jí)解決方案出現(xiàn)的，采用xml格式定義過程調(diào)用和返回，一個(gè)Soap消息就是一個(gè)特定格式和內(nèi)容的XML文檔。Restful web service：Rest 是針對(duì)Web提出的一種架構(gòu)風(fēng)格，Restful web service本質(zhì)上就是Web，任意一個(gè)URL地址，一個(gè)HTTP網(wǎng)頁都可以稱作是Restful web service。Rest把網(wǎng)絡(luò)上的所有事物抽象為資源，把對(duì)資源的操作抽象為CRUD，對(duì)應(yīng)HTTP的PUT，Get，Post，Delete。注意此處的資源不是靜態(tài)的數(shù)據(jù)，而是數(shù)據(jù)加上狀態(tài)，是隨時(shí)間變化的，每個(gè)資源有一個(gè)唯一的標(biāo)識(shí)，URL。Rest提出了一些設(shè)計(jì)概念和準(zhǔn)則： 1、網(wǎng)絡(luò)上的所有事物都被抽象為資源（resource）； 2、每個(gè)資源有一個(gè)唯一的資源標(biāo)識(shí)（resource identifier）； 3、通過通用的連接器接口（generic connector interface）對(duì)資源進(jìn)行操作； 4、對(duì)資源的各種操作不會(huì)改變資源標(biāo)識(shí)； 5、所有的操作都是無狀態(tài)的（stateless）。REST依賴一套簡(jiǎn)單的“動(dòng)詞”，把所有的復(fù)雜性都轉(zhuǎn)移到了指定資源的“名詞”中。與此不同，SOAP卻有一套相當(dāng)復(fù)雜的XML格式化命令和數(shù)據(jù)傳輸選項(xiàng)。在Web服務(wù)發(fā)展的初期，XML格式化消息的第一個(gè)主要用途是，應(yīng)用于XML-RPC協(xié)議，其中RPC代表遠(yuǎn)程過程調(diào)用。在XML遠(yuǎn)程過程調(diào) 用(XML-RPC)中，客戶端發(fā)送一條特定消息，該消息中必須包括名稱、運(yùn)行服務(wù)的程序以及輸入?yún)?shù)。相反， REST風(fēng)格的請(qǐng)求卻不關(guān)心正在運(yùn)行的程序是什么，它僅僅請(qǐng)求命名資源。 XML-RPC只能使用有限的數(shù)據(jù)類型種類和一些簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)。人們認(rèn)為這個(gè)協(xié)議還不夠強(qiáng)大，于是就出現(xiàn)了SOAP其最初的定義是簡(jiǎn)單 對(duì)象訪問協(xié)議。之后，大家逐漸意識(shí)到SOAP其實(shí)并不簡(jiǎn)單，而且也不需要必須使用面向?qū)ο笳Z言，所以，現(xiàn)在人們只是沿用SOAP這個(gè)名稱而已。 XML-RPC只有簡(jiǎn)單的數(shù)據(jù)類型集，取而代之，SOAP是通過利用XML Schema的不斷發(fā)展來定義數(shù)據(jù)類型的。同時(shí)，SOAP也能夠利用XML 命名空間，這是XML-RPC所不需要的。如此一來，SOAP消息的開頭部分就可以是任何類型的XML命名空間聲明，其代價(jià)是在系統(tǒng)之間增加了更多的復(fù)雜 性和不兼容性。 另外，非常重要一點(diǎn)是，REST是需要請(qǐng)求HTTP的，與其相比，SOAP更具優(yōu)勢(shì)，SOAP消息可以由所有能夠處理Unicode文本的傳 輸方式來傳送，很可惜，這一點(diǎn)通常不被人們所認(rèn)可。事實(shí)是，由于HTTP穿透防火墻的便捷性，以及開發(fā)商們對(duì)Web非常熟悉，因此，人們還在繼續(xù)強(qiáng)調(diào)著 HTTP傳輸。 隨著計(jì)算機(jī)行業(yè)的覺醒，人們發(fā)現(xiàn)了基于XML的Web服務(wù)的商業(yè)潛力，于是，各家公司開始不斷地發(fā)掘想法、觀點(diǎn)、論據(jù)以及標(biāo)準(zhǔn)化嘗試。W3C 曾經(jīng)設(shè)法以“Web服務(wù)活動(dòng)”的名義來組織成果展，其中也包括實(shí)際做出SOAP的XML協(xié)議工作組(XML Protocol Working Group)。與Web服務(wù)有關(guān)的標(biāo)準(zhǔn)化成果從某種程度上說與SOAP相關(guān)或者依賴于SOAP的數(shù)量已經(jīng)倍增了到了令人驚訝的程度。 最初，SOAP是作為XML-RPC的擴(kuò)展而發(fā)展起來的，它主要強(qiáng)調(diào)的是，通過從WSDL文件中所獲得的方法和變量名來進(jìn)行遠(yuǎn)程過程調(diào)用?，F(xiàn) 在，通過不斷進(jìn)步，人們發(fā)現(xiàn)了更多的使用SOAP的方式，而不僅僅是采用“文件”方式基本上是使用一個(gè)SOAP信封來傳送XML格式化文件。無論如 何，要掌握SOAP，了解WSDL所扮演的角色是最根本的。通過http請(qǐng)求的Accept Header字段來表示。針對(duì)SOAP Web服務(wù)的WSDL1.1僅支持HTTP POST方法。WSDL2.0通過包括對(duì)http get綁定的支持對(duì)此進(jìn)行了補(bǔ)充。另請(qǐng)注意，HTTP delete、put、trace和options方法是用并不頻繁，而且經(jīng)常被防火墻阻止。Soap與Rest區(qū)別：1 Soap也可以看作是一種風(fēng)格，面對(duì)的應(yīng)用需求是RPC，而Rest面對(duì)的應(yīng)用需求是分布式超媒體系統(tǒng)（Web）。2 Rest架構(gòu)風(fēng)格更強(qiáng)調(diào)數(shù)據(jù)，請(qǐng)求和響應(yīng)消息都是數(shù)據(jù)的封裝。而Soap風(fēng)格更強(qiáng)調(diào)接口，Soap消息封裝的是過程調(diào)用。REST是面向資源的，而Soap是面向接口的。3 REST架構(gòu)下，HTTP是承載協(xié)議，也是應(yīng)用協(xié)議，而Soap架構(gòu)下，HTTP只是承載協(xié)議，Soap才是應(yīng)用協(xié)議。Soap與REST的應(yīng)用場(chǎng)合：1 過程調(diào)用用soap。如果服務(wù)是作為一種功能提供，客戶端調(diào)用服務(wù)是為了執(zhí)行一個(gè)功能，用Soap，比如常見的認(rèn)證授權(quán)。而數(shù)據(jù)服務(wù)用REST。2 可以定義清晰明了的正式接口的情況下，用Soap，比如在企業(yè)應(yīng)用中，系統(tǒng)間的耦合采用面向接口的方式。3 要更多的考慮非功能需求，比如安全、傳輸、協(xié)作等需求，使用Soap。 4 低帶寬，客戶端的處理能力受限的場(chǎng)合，比如在PDA，手機(jī)上消費(fèi)服務(wù)，用REST。REST與SOAP之比較REST篇REST能夠在計(jì)算機(jī)領(lǐng)域被廣泛采用，它走的道路是不同尋常的。這個(gè)術(shù)語是由Roy Fielding創(chuàng)造的。在Web方面，我們必須承認(rèn)Fielding是非常精通的，他曾經(jīng)幫助創(chuàng)建HTTP 1.0規(guī)范，該規(guī)范從1996年開始就為Web提供基本準(zhǔn)則。我有這樣一個(gè)推斷，在計(jì)算機(jī)世界中，但凡那些讓開發(fā)人員記住的重要概念，都有一個(gè)很酷的名稱首字母縮寫，否則的話，開發(fā)人員很快就會(huì)將其拋之腦后。比如Ajax、SOAP以及REST就證明了這一點(diǎn)。REST能夠在計(jì)算機(jī)領(lǐng)域被廣泛采用，它走的道路是不同尋常的。這個(gè)術(shù)語是由Roy Fielding創(chuàng)造的。Fielding畢業(yè)于Irvine市加利福尼亞大學(xué)，在他的博士學(xué)位論文中第一次提出了REST這個(gè)概念。在Web方面，我們 必須承認(rèn)Fielding是非常精通的，他曾經(jīng)幫助創(chuàng)建HTTP 1.0規(guī)范，該規(guī)范從1996年開始就為Web提供基本準(zhǔn)則。他在Web標(biāo)準(zhǔn)方面非常有經(jīng)驗(yàn)，這為他的這篇博士論文奠定了堅(jiān)實(shí)的基礎(chǔ)。Fielding指出，使用且符合代表性狀態(tài)傳輸(REST)設(shè)計(jì)約束的 Web 上部署的組件，可以充分利用 Web 的有用特性，萬維網(wǎng)(World Wide Web)才能夠達(dá)到最佳的工作效果?？梢赃@樣理解REST當(dāng)一個(gè)瀏覽器得到并且顯示構(gòu)成HTML頁面的各個(gè)元素時(shí)，它正在獲取資源的當(dāng)前狀態(tài)的表現(xiàn)形 式。在Fielding的博士論文中，他列舉了REST風(fēng)格的設(shè)計(jì)約束，并且解釋了為什么這些約束能夠充分利用Web 的有用特性，使其達(dá)到最佳狀態(tài)，以及這些約束的關(guān)鍵所在。同時(shí)，在論文中，他也包含了一些關(guān)于REST和某些目前的Web風(fēng)格之間 “不符合”的討論，以及這些Web風(fēng)格是如何導(dǎo)致設(shè)計(jì)無法利用Web特性的。Fielding認(rèn)為，對(duì)于使用HTTP承載應(yīng)用程序協(xié)議穿越防火墻，XML-RPC 和SOAP所采用的方式是“從根本上被誤導(dǎo)的概念。”它們所采用的方式違背了設(shè)立防火墻的概念，結(jié)果是，防火墻廠商為了保護(hù)系統(tǒng)需要偵察出所承載的協(xié)議。 由于大多數(shù)SOAP應(yīng)用程序使用HTTP都是為了穿越防火墻，因此，你可以發(fā)現(xiàn)REST與SOAP之間的沖突是從哪里開始的。Fielding認(rèn)為，如果 你打算使用HTTP的話，就應(yīng)該與充分利用HTTP本身的含義。REST風(fēng)格強(qiáng)調(diào)，通過有限的操作或者是“動(dòng)詞”以及一個(gè)組件之間的標(biāo)準(zhǔn)接口，也就是HTTP協(xié)議提供的借口，來提升客戶與服務(wù)之間的交互。通 過為每一個(gè)資源分配其自己的URL，來實(shí)現(xiàn)靈活性，REST可以調(diào)用包含上百個(gè)URI的資源類型的客戶，其中的關(guān)鍵是REST能夠給你無限多的“名詞”。 REST使用HTTP的動(dòng)詞簡(jiǎn)單的良定義操作集:POST, GET, PUT,DELETE進(jìn)行請(qǐng)求和響應(yīng)，從而避免了歧義。舉個(gè)例子，GET只能夠簡(jiǎn)單地返回資源的表現(xiàn)形式，而不能夠創(chuàng)建任何其他的內(nèi)容。在Web發(fā)展的初期，由于人們都在試驗(yàn)通過收集各種不同來源的元素，從而把Web應(yīng)用程序融合在一起，有大量這種Web服務(wù)的不成熟探索的例子 從HTTP頁面中解析信息，用于頁面創(chuàng)建者沒有計(jì)劃到的用途。這種“屏幕抓取”的Web類比表明，REST風(fēng)格的方法是先于那些更加復(fù)雜的Web服務(wù) 而出現(xiàn)的。REST是一種風(fēng)格而不是一個(gè)標(biāo)準(zhǔn)你可能會(huì)把軟件的架構(gòu)風(fēng)格當(dāng)作對(duì)上層設(shè)計(jì)模式的抽象。然而，根據(jù)Fielding所說，設(shè)計(jì)模式的堆砌并不等同于架構(gòu)風(fēng)格，因?yàn)槟Ｊ绞欠浅＝咏谔囟▎栴}的。由于REST是超文本系統(tǒng)的一種風(fēng)格，而不是Web服務(wù)的，因此，本文的標(biāo)題“REST與SOAP之比較”就有些讓人誤解。然而，很多軟件設(shè)計(jì) 人員會(huì)將其混淆，他們?cè)诳紤]如何創(chuàng)建Web服務(wù)時(shí)，會(huì)得出這樣的結(jié)論：SOAP過于復(fù)雜，而簡(jiǎn)單的類似于REST的設(shè)計(jì)卻更加適合。REST與RPC風(fēng)格之比較遠(yuǎn)程過程調(diào)用的架構(gòu)，是應(yīng)用在基于XML-RPC或者 RPC風(fēng)格的SOAP的Web服務(wù)中的，它卻有著完全不同的風(fēng)格?？蛻舳税l(fā)出命令，以使服務(wù)做出特定的操作。換句話說，RPC有動(dòng)詞的傾向。REST強(qiáng)調(diào)資源(名詞)有統(tǒng)一的接口以此來對(duì)它們尋址，而RPC強(qiáng)調(diào)過程(動(dòng)詞)有統(tǒng)一的接口來激發(fā)它們。一個(gè)基于RPC的架構(gòu)，動(dòng)詞數(shù)量是 沒有限制的。REST說，我們使用四個(gè)動(dòng)詞非常熟悉，HTTP標(biāo)準(zhǔn)的GET、POST、PUT以及DELETE來進(jìn)行請(qǐng)求和響應(yīng)，REST使用資 源尋址來處理其可變性。一個(gè)簡(jiǎn)單的REST舉例假設(shè)我們希望一個(gè)Web服務(wù)暴露一部分目錄，從這個(gè)目錄中，用戶將能夠得到一些描述、圖片、安裝指令等等。為了得到數(shù)字“n1996-01”的描述，用戶需要格式化一個(gè)GET請(qǐng)求，類似于下面的這個(gè)URL：/catalog/description/n1996-01在處理這個(gè)請(qǐng)求時(shí)，“/catalog”將映射到一個(gè)服務(wù)中，之后，通過該服務(wù)對(duì)“description/n1996-01”進(jìn)行解釋，從而 定位資源。在創(chuàng)建響應(yīng)時(shí)，服務(wù)需要使用內(nèi)容類型(Content-Type)的頭文件來指定返回格式。在這種情況下，假定返回格式是HTML或者XML， 客戶端能夠使用它來控制頁面的布局。如果要得到圖片，那么這個(gè)請(qǐng)求將對(duì)“/catalog/picture/n1996-01”進(jìn)行尋址，返回的響應(yīng)將是 圖片內(nèi)容類型(Content-Type)。REST的商業(yè)應(yīng)用最近幾年，大多數(shù)Web商業(yè)企業(yè)開始對(duì)REST非常感興趣。Google Data API(目前還在測(cè)試版本)專門使用REST規(guī)則來提供簡(jiǎn)單的協(xié)議。對(duì)服務(wù)的HTTP GET請(qǐng)求的響應(yīng)結(jié)果是，采用Atom或者是RSS聯(lián)合格式的XML數(shù)據(jù)。Google也使用Atom以及POST、PUT和DELETE操作來完成公共 協(xié)議。eBay服務(wù)提供通過使用不同語言工具來訪問服務(wù)，這些工具包括文檔/文字風(fēng)格的SOAP以及REST風(fēng)格。那么，對(duì)于XML-RPC和SOAP所具有的RPC風(fēng)格而言，REST風(fēng)格是否是一個(gè)具有競(jìng)爭(zhēng)力的替代者呢?當(dāng)然，我決不這樣認(rèn)為，在下一篇文章中，我將盡量向大家展現(xiàn)SOAP所向無敵的領(lǐng)域。如今，Web開發(fā)者的可選技術(shù)相當(dāng)之多；從簡(jiǎn)化的數(shù)據(jù)庫訪問技術(shù)，到易用的中間件服務(wù)包裝技術(shù)，以及各種有趣的客戶端軟件等等，一應(yīng)俱全。所有這些產(chǎn)品和工具，都是為了幫助Web開發(fā)者用最快的速度開發(fā)出最好的Web應(yīng)用。然而，擁有大量可選軟件方案以及為Web應(yīng)用的特定部分選用特定方案，都是具有挑戰(zhàn)的事；而且，現(xiàn)在Web開發(fā)者必須持續(xù)跟蹤各種不斷變化著的標(biāo)準(zhǔn)與方法。舉個(gè)例子，Web服務(wù)技術(shù)就有SOAP（Simple Object Access Protocol，簡(jiǎn)單對(duì)象訪問協(xié)議）和REST（Representational State Transfer，表示性狀態(tài)轉(zhuǎn)移）這兩種方案。它們都是有效的方案，但在具體場(chǎng)合下采用哪種方案好，這要取決于Web開發(fā)者。目前，大部分Web開發(fā)者似乎都了解REST一種采用標(biāo)準(zhǔn)URI進(jìn)行調(diào)用的方案。REST很容易理解，而且只要是支持HTTP/HTTPS的客 戶端/服務(wù)器就支持它。你可以用HTTP GET方法來執(zhí)行命令。所以，開發(fā)者們感受到的REST的優(yōu)勢(shì)是：開發(fā)簡(jiǎn)單、只需依托現(xiàn)有Web基礎(chǔ)設(shè)施、以及學(xué)習(xí)成本低。然而，SOAP作為一種古老的Web服務(wù)技術(shù)，短期內(nèi)還不會(huì)退出歷史舞臺(tái)。而且，隨著SOAP 1.2的出現(xiàn)，SOAP印象中的一些缺點(diǎn)已得到改進(jìn)，采納率和易用程度也都得到提高。另需注意的是，從W3C SOAP 1.2版開始，SOAP這一縮寫不再代表Simple Object Access Protocol（簡(jiǎn)單對(duì)象訪問協(xié)議），而是僅僅作為協(xié)議名稱而已。相對(duì)REST而言，SOAP 1.2多出一些開銷，不過這些開銷也帶來了一些好處。首先，SOAP在三個(gè)方面離不開XML（Extensible Markup Language，可擴(kuò)展標(biāo)記語言）：SOAP信封（envelope）是基于XML的，它定義了消息里有什么以及如何處理它；一套用于數(shù)據(jù)類型的編碼規(guī) 則；過程調(diào)用和響應(yīng)的規(guī)劃。SOAP信封由傳輸協(xié)議（HTTP/HTTPS）發(fā)出，RPC（Remote Procedure Call，遠(yuǎn)程過程調(diào)用）得到執(zhí)行，然后一個(gè)XML文檔隨SOAP信封返回。需要注意的是，基于“通用”傳輸協(xié)議是SOAP的一個(gè)優(yōu)點(diǎn)。REST目前基于HTTP/HTTPS；而SOAP可支持任何傳輸協(xié)議，從HTTP /HTTPS到SMTP（Simple Mail Transfer Protocol，簡(jiǎn)單郵件傳送協(xié)議），甚至JMS（Java Messaging Service，Java消息傳遞服務(wù)）。不過，由于XML較為冗長(zhǎng)且解析費(fèi)時(shí)，因此采用XML也成為一個(gè)弊端。不過，對(duì)Web開發(fā)者來說的好消息是，目前上述兩種方案都是行之有效的方案。REST和SOAP都能解決許多Web方面的問題與挑戰(zhàn)，而且在許多情況下，它們各自都能滿足開發(fā)者的要求，也就是說可互換使用。但很多人不知道，這兩種技術(shù)可以混合搭配使用。REST很好理解，且極易上手；不過由于它缺乏標(biāo)準(zhǔn)，因此只被看作是一種架構(gòu)方法。與之相比，SOAP是一個(gè)工業(yè)標(biāo)準(zhǔn)，它具備良好定義的協(xié)議，以及一套良好確立的規(guī)則，在大型和小型系統(tǒng)中均有采用。因此，REST的適用場(chǎng)合包括： 有限的帶寬和資源 別忘了返回的結(jié)構(gòu)可以采用（由開發(fā)者定義的）任何格式。另外，由于REST采用標(biāo)準(zhǔn)的GET、PUT、POST和DELETE動(dòng)詞，因此可被任何瀏覽器所支持。除此以外，REST還可以使用為目前大多數(shù)瀏覽器支持的XMLHttpRequest對(duì)象，這為AJAX增色不少。 完全無狀態(tài)的操作 對(duì)于那些需多步執(zhí)行的操作，REST并非最佳選擇，采用SOAP更合適。但是，如果你需要無狀態(tài)的CRUD（Create/Read/Update/Delete，創(chuàng)建/讀取/更新/刪除）操作，那么應(yīng)采用REST。 緩存考慮 若要利用無狀態(tài)操作的特性，使得信息可被緩存，那么REST是很好的選擇。以上已經(jīng)覆蓋很多方案了，那么，為什么還要考慮SOAP呢？正如前述，SOAP比較成熟而且是經(jīng)過良好定義的，具有完整的規(guī)范。而REST只不過是一種方法，對(duì)開發(fā)未作任何規(guī)約；因此，假如你遇到以下場(chǎng)合，那么SOAP是最佳選擇： 異步處理與調(diào)用 如果你的應(yīng)用需要確?？煽啃耘c安全性，那么請(qǐng)采用SOAP。SOAP 1.2為確保這種操作補(bǔ)充定義了WSRM（WS-Reliable Messaging）等標(biāo)準(zhǔn)。 形式化契約 若提供者/消費(fèi)者雙方必須就交換格式取得一致，那么采用SOAP更合適。SOAP 1.2為這種交互提供了嚴(yán)格的規(guī)范。 有狀態(tài)的操作 如果應(yīng)用需要上下文信息與對(duì)話狀態(tài)管理，那么應(yīng)采用SOAP。SOAP 1.2為此補(bǔ)充定義了WS-Security、WS-Transactions和WS-Coordination等標(biāo)準(zhǔn)。相比之下，REST方法要求開發(fā)者自己來實(shí)現(xiàn)這些框架性工作。正如你所看到的，REST和SOAP各自有其用武之地。它們?cè)诎踩院蛡鬏攲拥确矫嬗兄约旱臐撛趩栴}，不過它們都能完成任務(wù)，而且在許多情況下， 它們都豐富了Web的技術(shù)手段。因此，就這一論題，其實(shí)最好的原則就是靈活性原則；因?yàn)橹辽僭诂F(xiàn)今的Web開發(fā)中，無論面對(duì)何種問題，Web開發(fā)者們總有 辦法運(yùn)用好這兩種技術(shù)中的一種。關(guān)于作者M(jìn)ike Rozlog是Embarcadero科技公司的高級(jí)產(chǎn)品主管。他的主要工作是確保Embarcadero公司推出開發(fā)工具滿足全世界開發(fā)者們的期望。他 的大部分時(shí)間被致力于從技術(shù)和業(yè)務(wù)兩個(gè)方面來介紹講解Embarcadero的產(chǎn)品與服務(wù)，其聽眾是遍布全球分析師及其他聽眾。Mike曾工作于 CodeGear，一個(gè)于2008年被Embarcadero收購的開發(fā)工具團(tuán)隊(duì)。之前，他為Borland公司工作了八年，擔(dān)任過包括首席技術(shù)架構(gòu)師在 內(nèi)的許多職位。作為一名知名作者，Mike出版了很多書。他最近的作品Mastering JBuilder已由John Wiley & Sons出版。REST與SOAP之比較SOAP篇作者: William Brogden, 出處:TechTarget,責(zé)任編輯: 葉江,2006-12-29 10:00本文的標(biāo)題“REST與SOAP之比較”確實(shí)有些讓人誤解。REST是代表性狀態(tài)傳輸?shù)拿Q首字母縮寫，與 其說它是標(biāo)準(zhǔn)，不如說是一種風(fēng)格。然而，在我的前一篇文章中，正如我們所討論的，眾多從事Web服務(wù)的軟件設(shè)計(jì)師們認(rèn)為SOAP過度復(fù)雜，于是，類似 eBay和Google的服務(wù)都采用了REST風(fēng)格的約束來暴露其大量數(shù)據(jù)。本文的標(biāo)題“REST 與SOAP之比較”確實(shí)有些讓人誤解。REST是代表性狀態(tài)傳輸?shù)拿Q首字母縮寫，與其說它是標(biāo)準(zhǔn)，不如說是一種風(fēng)格。然而，在我的前一篇文章中，正如我 們所討論的，眾多從事Web服務(wù)的軟件設(shè)計(jì)師們認(rèn)為SOAP過度復(fù)雜，于是，類似eBay和Google的服務(wù)都采用了REST風(fēng)格的約束來暴露其大量數(shù) 據(jù)。查看第一部分比較REST和SOAP的“風(fēng)格”REST依賴一套簡(jiǎn)單的“動(dòng)詞”，把所有的復(fù)雜性都轉(zhuǎn)移到了指定資源的“名詞”中。與此不同，SOAP卻有一套相當(dāng)復(fù)雜的XML格式化命令和數(shù)據(jù)傳輸選項(xiàng)。在Web服務(wù)發(fā)展的初期，XML格式化消息的第一個(gè)主要用途是，應(yīng)用于XML-RPC協(xié)議，其中RPC代表遠(yuǎn)程過程調(diào)用。在XML遠(yuǎn)程過程調(diào)用 (XML-RPC)中，客戶端發(fā)送一條特定消息，該消息中必須包括名稱、運(yùn)行服務(wù)的程序以及輸入?yún)?shù)。相反， REST風(fēng)格的請(qǐng)求卻不關(guān)心正在運(yùn)行的程序是什么，它僅僅請(qǐng)求命名資源。XML-RPC只能使用有限的數(shù)據(jù)類型種類和一些簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)。人們認(rèn)為這個(gè)協(xié)議還不夠強(qiáng)大，于是就出現(xiàn)了SOAP其最初的定義是簡(jiǎn)單對(duì) 象訪問協(xié)議。之后，大家逐漸意識(shí)到SOAP其實(shí)并不簡(jiǎn)單，而且也不需要必須使用面向?qū)ο笳Z言，所以，現(xiàn)在人們只是沿用SOAP這個(gè)名稱而已。XML-RPC只有簡(jiǎn)單的數(shù)據(jù)類型集，取而代之，SOAP是通過利用XML Schema的不斷發(fā)展來定義數(shù)據(jù)類型的。同時(shí)，SOAP也能夠利用XML 命名空間，這是XML-RPC所不需要的。如此一來，SOAP消息的開頭部分就可以是任何類型的XML命名空間聲明，其代價(jià)是在系統(tǒng)之間增加了更多的復(fù)雜 性和不兼容性。另外，非常重要一點(diǎn)是，REST是需要請(qǐng)求HTTP的，與其相比，SOAP更具優(yōu)勢(shì)，SOAP消息可以由所有能夠處理Unicode文本的傳輸 方式來傳送，很可惜，這一點(diǎn)通常不被人們所認(rèn)可。事實(shí)是，由于HTTP穿透防火墻的便捷性，以及開發(fā)商們對(duì)Web非常熟悉，因此，人們還在繼續(xù)強(qiáng)調(diào)著 HTTP傳輸。隨著計(jì)算機(jī)行業(yè)的覺醒，人們發(fā)現(xiàn)了基于XML的Web服務(wù)的商業(yè)潛力，于是，各家公司開始不斷地發(fā)掘想法、觀點(diǎn)、論據(jù)以及標(biāo)準(zhǔn)化嘗試。W3C曾 經(jīng)設(shè)法以“Web服務(wù)活動(dòng)”的名義來組織成果展，其中也包括實(shí)際做出SOAP的XML協(xié)議工作組(XML Protocol Working Group)。與Web服務(wù)有關(guān)的標(biāo)準(zhǔn)化成果從某種程度上說與SOAP相關(guān)或者依賴于SOAP的數(shù)量已經(jīng)倍增了到了令人驚訝的程度。最初，SOAP是作為XML-RPC的擴(kuò)展而發(fā)展起來的，它主要強(qiáng)調(diào)的是，通過從WSDL文件中所獲得的方法和變量名來進(jìn)行遠(yuǎn)程過程調(diào)用?，F(xiàn) 在，通過不斷進(jìn)步，人們發(fā)現(xiàn)了更多的使用SOAP的方式，而不僅僅是采用“文件”方式基本上是使用一個(gè)SOAP信封來傳送XML格式化文件。無論如 何，要掌握SOAP，了解WSDL所扮演的角色是最根本的。Web服務(wù)描述語言或WSDL為了創(chuàng)建一個(gè)用于描述Web服務(wù)的XML格式化文件，Web服務(wù)描述語言(WSDL)標(biāo)準(zhǔn)提供了足夠多的細(xì)節(jié)，以便能夠構(gòu)建出客戶端代碼，從而訪問服務(wù)或者服務(wù)器端代碼以提供服務(wù)。一個(gè)服務(wù)的WSDL文件將會(huì)為你提供以下幾個(gè)方面的內(nèi)容： 用于訪問服務(wù)的地址信息 用于傳送信息的傳輸協(xié)議(例如，通道數(shù)) 用于所有可使用功能的名稱和接口使用方法 在所有的請(qǐng)求和響應(yīng)中所使用的數(shù)據(jù)類型2001年3月，W3C推出了WSDL 1.1版本用于討論，這并不是最終確定的規(guī)范。W3C Web服務(wù)描述工作組目前正在開發(fā)該規(guī)范的2.0版本，基本上已經(jīng)到了尾聲。雖然，WSDL通常是用于特定的SOAP服務(wù)，但是，從理論說，它是完全可以 用于特定的REST風(fēng)格的GET或者POST操作的。能夠根據(jù)服務(wù)的WSDL描述來自動(dòng)創(chuàng)建客戶端和服務(wù)器端代碼，支持這一功能的開發(fā)環(huán)境目前使用得很廣泛，以便能夠適用于Web服務(wù)器和Web服 務(wù)客戶端的不同程序設(shè)計(jì)語言。如果你使用Google搜索“SOAP IDE”的話，大概會(huì)出現(xiàn)上百萬條相關(guān)信息。也有這樣的工具，根據(jù)Java或C#對(duì)象來生成相應(yīng)的WSDL和代碼。自動(dòng)生成代碼也許能夠使你的開發(fā)效率更 高，但是離優(yōu)化卻是越來越遠(yuǎn)。安全與SOAP如果企業(yè)使用SOAP來傳送有價(jià)值的信息的話，那么，安全就是最重要的問題。由OASIS組織發(fā)起，計(jì)算機(jī)行業(yè)的領(lǐng)導(dǎo)者們已經(jīng)聯(lián)合開發(fā)了一套標(biāo)準(zhǔn)，稱為WS-Security。這個(gè)標(biāo)準(zhǔn)對(duì)基本的SOAP通信做出了改善，以便能夠處理以下幾個(gè)問題：消息機(jī)密性由于攔截HTTP消息的方式非常多，因此，在請(qǐng)求和響應(yīng)過程中，必須能夠?qū)λ兄匾畔⒓用?。很幸運(yùn)，現(xiàn)在的加密技術(shù)非常先進(jìn)，我們能夠?qū)ο?nèi)容進(jìn)行加密，以保證消息不被修改?？蛻艉头?wù)身份必須能夠核實(shí)SOAP請(qǐng)求來源的身份。結(jié)論在開發(fā)人員的意識(shí)里，對(duì)于Web服務(wù)的開發(fā)而言，REST和SOAP風(fēng)格各有千秋。SOAP擁有更為詳盡的標(biāo)準(zhǔn)化成果和開源工具。除此之外，現(xiàn) 在，有許多集成開發(fā)環(huán)境能夠在現(xiàn)有代碼的基礎(chǔ)上，依據(jù)接口方法自動(dòng)生成SOAP。如果你需要使用WSDL來發(fā)布你的服務(wù)，或者你需要一些安全功能如消息簽 名和加密，那么，SOAP能夠確保消息的安全性。另一方面，如果你希望使用簡(jiǎn)單接口來公布一些信息，而不需要繁瑣的處理過程，那么，REST也許是最佳選 擇。REST(Representational State Transfer)是HTTP協(xié)議的作者Roy Fielding博士在其博士論文中提出的一種互聯(lián)網(wǎng)應(yīng)用構(gòu)架風(fēng)格。與以遠(yuǎn)程對(duì)象為核心的ORB和以服務(wù)為核心的SOA相比，以資源為核心的REST讓我們從嶄新的視角審視互聯(lián)網(wǎng)應(yīng)用。REST為互聯(lián)網(wǎng)應(yīng)用量身定做的簡(jiǎn)潔模型、與HTTP協(xié)議的完美結(jié)合、構(gòu)架的高擴(kuò)展性，為互聯(lián)網(wǎng)應(yīng)用構(gòu)架設(shè)計(jì)和異構(gòu)系統(tǒng)集成設(shè)計(jì)帶來了一股清新的空氣。語言生態(tài)環(huán)境計(jì)算機(jī)發(fā)展至今，產(chǎn)生了許許多多不同的語言，每種語言都定義了自己獨(dú)特的生態(tài)環(huán)境。在這個(gè)生態(tài)環(huán)境內(nèi)的程序共享相同的類 型系統(tǒng)、運(yùn)行時(shí)環(huán)境、并發(fā)模型等。雖然所有程序的本質(zhì)是相同的：從問題領(lǐng)域到機(jī)器領(lǐng)域的映射，但無法回避的是不同生態(tài)環(huán)境的程序很難跨越彼此的邊界。同樣 是int，在A和B語言通常截然不同（CLR和JVM能部分解決類型共享問題），更不用說A語言具有但B語言不具有的某些語言特性(CLR和JVM沒法解決)。當(dāng)系統(tǒng)可以在單一的生態(tài)環(huán)境中自給自足時(shí)，跨越生態(tài)環(huán)境的問題并不存在；但在多數(shù)互聯(lián)網(wǎng)應(yīng)用中，系統(tǒng)的各個(gè)部分通常既是生產(chǎn)者又是消費(fèi)者，必須要打破生態(tài)環(huán)境的界限才能相互協(xié)作。比如，A公司的Service A，需要對(duì)外提供服務(wù)，而Service A又依賴于B公司的Service B和C公司的Service C；由于無法保證不同公司都采用同樣的語言，因此各服務(wù)的接口必須保證語言無關(guān)性。在我所了解的范圍內(nèi)，有3種跨域生態(tài)環(huán)境的方式：1. ORB(Object Request Broker)以CORBA為代表，其核心概念是遠(yuǎn)程對(duì)象（remote object）。熟悉.Net Remoting的朋友應(yīng)該能體會(huì)其風(fēng)格（需要說明的是.Net Remoting只跨越微軟的生態(tài)環(huán)境）。不同生態(tài)環(huán)境的程序可以像調(diào)用本地對(duì)象一樣調(diào)用遠(yuǎn)程對(duì)象代理的方法，ORB會(huì)負(fù)責(zé)連接到遠(yuǎn)程的對(duì)象，并處理數(shù)據(jù)的序列化與反序列化。2. SOA其核心概念是服務(wù)(Service)。比如：我們要提供整數(shù)加法Web服務(wù)，我們會(huì)很自然地想到通過類似下面的url來表達(dá)服務(wù)接口：/add?a=1&b=2并通過xml結(jié)構(gòu)表達(dá)結(jié)果：3. REST其核心概念是資源(Resource)。在REST的世界中，沒有服務(wù)的概念，同樣是上面的例子，在REST的世界中，/add?a=1&b=2是一個(gè)xml網(wǎng)頁資源的id，而非服務(wù)的接口。所以，REST讓我們從資源的角度來審視互聯(lián)網(wǎng)應(yīng)用并指導(dǎo)我們的設(shè)計(jì)，這是它與ORB和SOA最本質(zhì)的區(qū)別。下面我們將更詳細(xì)的介紹，REST以資源為核心的模型和相應(yīng)的設(shè)計(jì)風(fēng)格。狀態(tài)表述轉(zhuǎn)移在REST的世界中，資源即狀態(tài)，而互聯(lián)網(wǎng)就是一個(gè)巨大的狀態(tài)機(jī)：每個(gè)網(wǎng)頁是其一個(gè)狀態(tài)；url是狀態(tài)的表述；REST風(fēng)格的應(yīng)用則是從一個(gè)狀態(tài)遷移到下一個(gè)狀態(tài)的狀態(tài)轉(zhuǎn)移過程。早期互聯(lián)網(wǎng)只有靜態(tài)頁面的時(shí)候，通過超鏈接在靜態(tài)網(wǎng)頁間瀏覽跳轉(zhuǎn)的page-link-page-link模式就是一種典型的狀態(tài)轉(zhuǎn)移過程。無狀態(tài)服務(wù)器REST風(fēng)格應(yīng)用可以實(shí)現(xiàn)交互，但它卻天然地具有服務(wù)器無狀態(tài)的特征。在狀態(tài)遷移的過程中，服務(wù)器不需要記錄任何Session，所有的狀態(tài)都通過url的形式記錄在了客戶端。PS:更準(zhǔn)確地說，這里的無狀態(tài)服務(wù)器，是指服務(wù)器不保存會(huì)話狀態(tài)(Session)；而資源本身則是天然的狀態(tài)，通常是需要被保存的；本文提到的無狀態(tài)服務(wù)器均指無會(huì)話狀態(tài)服務(wù)器。舉個(gè)例子：一個(gè)心理測(cè)試的應(yīng)用，需要用戶做2次選擇題，每次可選A、B兩種答案，2次選擇完畢之后將告知用戶屬于何種心理類型。如果按ORB或SOA的服務(wù)思維，很容易想到在服務(wù)器端保存Session，每次選擇以后修改Session，根據(jù)Session產(chǎn)生結(jié)果。但如果以REST的狀態(tài)表述轉(zhuǎn)移模型為指導(dǎo)，我們會(huì)自然地得出這樣設(shè)計(jì)：每一個(gè)頁面表示一個(gè)狀態(tài)（存在于客戶端），頁面包含了到下一個(gè)頁面的超鏈接，每當(dāng)用戶選a或選b時(shí)分別轉(zhuǎn)移到下一個(gè)相應(yīng)的狀態(tài)。這樣，所有的會(huì)話狀態(tài)其實(shí)都是通過url的形式保存在了客戶端，服務(wù)器端實(shí)現(xiàn)了無狀態(tài)。另外，需要說明的是，雖然上圖有7個(gè)狀態(tài)，但并非一定需要在服務(wù)器預(yù)先生成7個(gè)靜態(tài)頁面，它們完全可以是動(dòng)態(tài)頁面，這不影響狀態(tài)轉(zhuǎn)移的概念模型以及服務(wù)器無狀態(tài)的特征。有構(gòu)架設(shè)計(jì)經(jīng)驗(yàn)的朋友應(yīng)該很清楚，與有狀態(tài)服務(wù)設(shè)計(jì)相比，無狀態(tài)服務(wù)容易實(shí)現(xiàn)系統(tǒng)性能的橫向擴(kuò)展。通過增加硬件，部署多個(gè)無狀態(tài)服務(wù)，并進(jìn)行l(wèi)oad balance不會(huì)受到制約；而有狀態(tài)服務(wù)模式，Session的存儲(chǔ)、共享都會(huì)帶來性能瓶頸，且無法通過增加硬件消除。Google搜索就是一個(gè)典型的無狀態(tài)服務(wù)。試想一下，當(dāng)你搜索“周杰倫”以后，Google提示你有數(shù)百萬的結(jié)果，并每10條一頁分成若干 頁，Google會(huì)把結(jié)果保存進(jìn)服務(wù)器Session嗎，然后當(dāng)你翻頁的時(shí)候，再從Session中取嗎？顯然這樣龐大的Session，即使是 Google也無法承受。來看看Google的url：第一頁：/search?q=%E5%91%A8%E6%9D%B0%E4%BC%A6&hl=zh-CN&newwindow=1&start=0&sa=N 第二頁：/search?q=%E5%91%A8%E6%9D%B0%E4%BC%A6&hl=zh-CN&newwindow=1&start=10&sa=NGoogle把搜索結(jié)果的每一頁視為資源（狀態(tài)），并通過url來表示，同一搜索關(guān)鍵字的不同分頁通過start參數(shù)來進(jìn)行區(qū)分。當(dāng)你從第一頁點(diǎn)擊第二頁 的鏈接時(shí)，只是從一個(gè)狀態(tài)跳到了下一個(gè)狀態(tài)而已；對(duì)于Google而言，其實(shí)是一條新的查詢（按REST的觀點(diǎn)，獲取新的資源），而兩次查詢很可能是由不 同的服務(wù)器在處理，而用戶卻感覺Google似乎記住了會(huì)話。從上面的例子中，我們初步體會(huì)到了一點(diǎn)REST風(fēng)格的味道。但需要說明，REST風(fēng)格包含了無狀態(tài)服務(wù)器的特征；但反過來，并非具有無狀態(tài)服務(wù)器特征的都是REST。SOA同樣可以是無狀態(tài)的，REST的核心還是資源。RIA+REST，琴瑟合鳴2009-05-17 23:43 by Flyingis, 3649 visits, 網(wǎng)摘, 收藏, 編輯 Flyingis 在當(dāng)前IT概念名詞漫天飛舞的年代，REST+RIA已經(jīng)開始逐漸成為一種開發(fā)應(yīng)用模式的標(biāo)準(zhǔn)，并越來越多的在各種實(shí)際業(yè)務(wù)中得到應(yīng)用。 記得第一次看到REST的身影，是在InfoQ上的一篇介紹，隨后又翻閱了后面的參考文章和Developerwork上一些資料，甚至隨手翻了翻Roy博士的論文。 所幸，在不少人還在體會(huì)REST到底是何方神圣的時(shí)候，我拿到并安裝了最新版的ArcGIS Server 9.3，里面新增了一種新的GIS服務(wù)：ArcGIS Server REST服務(wù)。有了這樣的一個(gè)落地的基于REST的服務(wù)，所有對(duì)REST基礎(chǔ)概念的疑惑都迎刃而解：為所有“事務(wù)”定義ID；將所有“事務(wù)”鏈接在一起； 使用標(biāo)準(zhǔn)方法；資源多重表述；無狀態(tài)通信（摘抄自InfoQ）。所以，學(xué)習(xí)開發(fā)或開發(fā)理念，看文字沒有看圖片快，看圖片沒有動(dòng)手操作快，動(dòng)手操作沒有導(dǎo)師親自指導(dǎo)快，對(duì)于REST的學(xué)習(xí)，我對(duì)生澀的文字概念的理解時(shí)間被壓縮到了最小。 ArcGIS Server REST服務(wù)的組織結(jié)構(gòu)： 今天看到一則新聞，紐約時(shí)報(bào)通過Times Developer Network構(gòu)建了一個(gè)基于REST的API，請(qǐng)求API之后將得到XML和JSON格式的返回?cái)?shù)據(jù)，這些API包括：ArticleSearchAPI：能夠搜索從1981年到現(xiàn)在紐約時(shí)報(bào)上的文章，可以獲取標(biāo)題、摘要及相關(guān)多媒體的鏈接BestSellersAPI：能夠獲取紐約時(shí)報(bào)所有的最佳業(yè)績(jī)數(shù)據(jù)，包括特定銷售商的等級(jí)歷史CampaignFinanceAPI：根據(jù)美國聯(lián)邦選舉委員會(huì)的備案獲取總統(tǒng)選舉的捐助及花費(fèi)數(shù)據(jù)CommunityAPI：獲取NYT用戶發(fā)表的評(píng)論CongressAPI：獲取美國議會(huì)投票數(shù)據(jù)，包括具體議院和參議院議員的信息MovieReviewsAPI：獲取到評(píng)論和紐約時(shí)報(bào)評(píng)論家的鏈接以及根據(jù)關(guān)鍵字搜索電影評(píng)論NewYorkStateLegislatureAPI：獲取紐約州參議