REST SOAP XML-RPC分析比較

本文的標題「REST與SOAP之比較」確實有些讓人誤解。REST是表明性狀態傳輸的名稱首字母縮寫，與其說它是標準，不如說是一種風格。然而，在個人前一篇文章中，正如咱們所討論的，衆多從事Web服務的軟件設計師們認爲SOAP過分複雜，因而，相似eBay和Google的服務都採用了REST風格的約束來暴露其大量數據。

        我有這樣一個推斷，在計算機世界中，但凡那些讓開發人員記住的重要概念，都有一個很酷的名稱首字母縮寫，不然的話，開發人員很快就會將其拋之腦後。好比Ajax、SOAP以及REST就證實了這一點。

　　REST可以在計算機領域被普遍採用，它走的道路是不一樣尋常的。這個術語是由Roy Fielding創造的。Fielding畢業於Irvine市加利福尼亞大學，在他的博士學位論文中第一次提出了REST這個概念。在Web方面，咱們必須認可Fielding是很是精通的，他曾經幫助建立HTTP 1.0規範，該規範從1996年開始就爲Web提供基本準則。他在Web標準方面很是有經驗，這爲他的這篇博士論文奠基了堅實的基礎。

　　Fielding指出，使用且符合表明性狀態傳輸(REST)設計約束的 Web 上部署的組件，能夠充分利用 Web 的有用特性，萬維網(World Wide Web)纔可以達到最佳的工做效果。能夠這樣理解REST——當一個瀏覽器獲得而且顯示構成HTML頁面的各個元素時，它正在獲取資源的當前狀態的表現形式。在Fielding的博士論文中，他列舉了REST風格的設計約束，而且解釋了爲何這些約束可以充分利用Web 的有用特性，使其達到最佳狀態，以及這些約束的關鍵所在。同時，在論文中，他也包含了一些關於REST和某些目前的Web風格之間 「不符合」的討論，以及這些Web風格是如何致使設計沒法利用Web特性的。

　　Fielding認爲，對於使用HTTP承載應用程序協議穿越防火牆，XML-RPC 和SOAP所採用的方式是「從根本上被誤導的概念。」它們所採用的方式違背了設立防火牆的概念，結果是，防火牆廠商爲了保護系統須要偵察出所承載的協議。因爲大多數SOAP應用程序使用HTTP都是爲了穿越防火牆，所以，你能夠發現REST與SOAP之間的衝突是從哪裏開始的。Fielding認爲，若是你打算使用HTTP的話，就應該與充分利用HTTP自己的含義。

　　REST風格強調，經過有限的操做或者是「動詞」以及一個組件之間的標準接口，也就是HTTP協議提供的藉口，來提高客戶與服務之間的交互。經過爲每個資源分配其本身的URL，來實現靈活性，REST能夠調用包含上百個URI的資源類型的客戶，其中的關鍵是REST可以給你無限多的「名詞」。REST使用HTTP的動詞——簡單的良定義操做集:POST, GET, PUT,DELETE進行請求和響應，從而避免了歧義。舉個例子，GET只可以簡單地返回資源的表現形式，而不可以建立任何其餘的內容。

　　在Web發展的初期，因爲人們都在試驗經過收集各類不一樣來源的元素，從而把Web應用程序融合在一塊兒，有大量這種Web服務的不成熟探索的例子——從HTTP頁面中解析信息，用於頁面建立者沒有計劃到的用途。這種「屏幕抓取」的Web類比代表，REST風格的方法是先於那些更加複雜的Web服務而出現的。

　　REST是一種風格而不是一個標準

　　你可能會把軟件的架構風格看成對上層設計模式的抽象。然而，根據Fielding所說，設計模式的堆砌並不等同於架構風格，由於模式是很是接近於特定問題的。

　　因爲REST是超文本系統的一種風格，而不是Web服務的，所以，本文的標題「REST與SOAP之比較」就有些讓人誤解。然而，不少軟件設計人員會將其混淆，他們在考慮如何建立Web服務時，會得出這樣的結論：SOAP過於複雜，而簡單的相似於REST的設計卻更加適合。

　　REST與RPC風格之比較

　　遠程過程調用的架構，是應用在基於XML-RPC或者 RPC風格的SOAP的Web服務中的，它卻有着徹底不一樣的風格。客戶端發出命令，以使服務作出特定的操做。換句話說，RPC有動詞的傾向。

　　REST強調資源(名詞)有統一的接口以此來對它們尋址，而RPC強調過程(動詞)有統一的接口來激發它們。一個基於RPC的架構，動詞數量是沒有限制的。REST說，咱們使用四個動詞——很是熟悉，HTTP標準的GET、POST、PUT以及DELETE——來進行請求和響應，REST使用資源尋址來處理其可變性。

　　一個簡單的REST舉例

　　假設咱們但願一個Web服務暴露一部分目錄，從這個目錄中，用戶將可以獲得一些描述、圖片、安裝指令等等。爲了獲得數字「n1996-01」的描述，用戶須要格式化一個GET請求，相似於下面的這個URL：

　　http://company.com/catalog/description/n1996-01

　　在處理這個請求時，「/catalog」將映射到一個服務中，以後，經過該服務對「description/n1996-01」進行解釋，從而定位資源。在建立響應時，服務須要使用內容類型(Content-Type)的頭文件來指定返回格式。在這種狀況下，假定返回格式是HTML或者XML，客戶端可以使用它來控制頁面的佈局。若是要獲得圖片，那麼這個請求將對「/catalog/picture/n1996-01」進行尋址，返回的響應將是圖片內容類型(Content-Type)。

　　REST的商業應用

　　最近幾年，大多數Web商業企業開始對REST很是感興趣。Google Data API(目前還在測試版本)專門使用REST規則來提供簡單的協議。對服務的HTTP GET請求的響應結果是，採用Atom或者是RSS聯合格式的XML數據。Google也使用Atom以及POST、PUT和DELETE操做來完成公共協議。eBay服務提供經過使用不一樣語言工具來訪問服務，這些工具包括文檔/文字風格的SOAP以及REST風格。

　　那麼，對於XML-RPC和SOAP所具備的RPC風格而言，REST風格是不是一個具備競爭力的替代者呢?固然，我決不這樣認爲，在下一篇文章中，我將盡可能向你們展示SOAP所向無敵的領域。

　　比較REST和SOAP的「風格」

　　REST依賴一套簡單的「動詞」，把全部的複雜性都轉移到了指定資源的「名詞」中。與此不一樣，SOAP卻有一套至關複雜的XML格式化命令和數據傳輸選項。

　　在Web服務發展的初期，XML格式化消息的第一個主要用途是，應用於XML-RPC協議，其中RPC表明遠程過程調用。在XML遠程過程調用(XML-RPC)中，客戶端發送一條特定消息，該消息中必須包括名稱、運行服務的程序以及輸入參數。相反， REST風格的請求卻不關心正在運行的程序是什麼，它僅僅請求命名資源。

　　XML-RPC只能使用有限的數據類型種類和一些簡單的數據結構。人們認爲這個協議還不夠強大，因而就出現了SOAP——其最初的定義是簡單對象訪問協議。以後，你們逐漸意識到SOAP其實並不簡單，並且也不須要必須使用面嚮對象語言，因此，如今人們只是沿用SOAP這個名稱而已。

　　XML-RPC只有簡單的數據類型集，取而代之，SOAP是經過利用XML Schema的不斷髮展來定義數據類型的。同時，SOAP也可以利用XML 命名空間，這是XML-RPC所不須要的。如此一來，SOAP消息的開頭部分就能夠是任何類型的XML命名空間聲明，其代價是在系統之間增長了更多的複雜性和不兼容性。

　　另外，很是重要一點是，REST是須要請求HTTP的，與其相比，SOAP更具優點，SOAP消息能夠由全部可以處理Unicode文本的傳輸方式來傳送，很惋惜，這一點一般不被人們所承認。事實是，因爲HTTP穿透防火牆的便捷性，以及開發商們對Web很是熟悉，所以，人們還在繼續強調着HTTP傳輸。

　　隨着計算機行業的覺醒，人們發現了基於XML的Web服務的商業潛力，因而，各家公司開始不斷地發掘想法、觀點、論據以及標準化嘗試。W3C曾經設法以「Web服務活動」的名義來組織成果展，其中也包括實際作出SOAP的XML協議工做組(XML Protocol Working Group)。與Web服務有關的標準化成果——從某種程度上說與SOAP相關或者依賴於SOAP——的數量已經倍增了到了使人驚訝的程度。

　　最初，SOAP是做爲XML-RPC的擴展而發展起來的，它主要強調的是，經過從WSDL文件中所得到的方法和變量名來進行遠程過程調用。如今，經過不斷進步，人們發現了更多的使用SOAP的方式，而不只僅是採用「文件」方式——基本上是使用一個SOAP信封來傳送XML格式化文件。不管如何，要掌握SOAP，瞭解WSDL所扮演的角色是最根本的。

　　Web服務描述語言或WSDL

　　爲了建立一個用於描述Web服務的XML格式化文件，Web服務描述語言(WSDL)標準提供了足夠多的細節，以便可以構建出客戶端代碼，從而訪問服務或者服務器端代碼以提供服務。一個服務的WSDL文件將會爲你提供如下幾個方面的內容：

　　用於訪問服務的地址信息　　用於傳送信息的傳輸協議(例如，通道數)　　用於全部可以使用功能的名稱和接口使用方法　　在全部的請求和響應中所使用的數據類型

　　2001年3月，W3C推出了WSDL 1.1版本用於討論，這並非最終肯定的規範。W3C Web服務描述工做組目前正在開發該規範的2.0版本，基本上已經到了尾聲。雖然，WSDL一般是用於特定的SOAP服務，可是，從理論說，它是徹底能夠用於特定的REST風格的GET或者POST操做的。

　　可以根據服務的WSDL描述來自動建立客戶端和服務器端代碼，支持這一功能的開發環境目前使用得很普遍，以便可以適用於Web服務器和Web服務客戶端的不一樣程序設計語言。若是你使用Google搜索「SOAP IDE」的話，大概會出現上百萬條相關信息。也有這樣的工具，根據Java或C#對象來生成相應的WSDL和代碼。自動生成代碼也許可以使你的開發效率更高，可是離優化倒是愈來愈遠。

　　安全與SOAP

　　若是企業使用SOAP來傳送有價值的信息的話，那麼，安全就是最重要的問題。由OASIS組織發起，計算機行業的領導者們已經聯合開發了一套標準，稱爲WS-Security。這個標準對基本的SOAP通訊作出了改善，以便可以處理如下幾個問題：

　　消息機密性——因爲攔截HTTP消息的方式很是多，所以，在請求和響應過程當中，必須可以對全部重要信息加密。很幸運，如今的加密技術很是先進，咱們可以對消息內容進行加密，以保證消息不被修改。

　　客戶和服務身份——必須可以覈實SOAP請求來源的身份。

　　結論

　　在開發人員的意識裏，對於Web服務的開發而言，REST和SOAP風格各有千秋。SOAP擁有更爲詳盡的標準化成果和開源工具。除此以外，如今，有許多集成開發環境可以在現有代碼的基礎上，依據接口方法自動生成SOAP。若是你須要使用WSDL來發布你的服務，或者你須要一些安全功能如消息簽名和加密，那麼，SOAP可以確保消息的安全性。另外一方面，若是你但願使用簡單接口來公佈一些信息，而不須要繁瑣的處理過程，那麼，REST也許是最佳選擇。

-------------------------------------------------------------------------------------------------------------------------------------------

http://it.chinawin.net/softwaredev/article-1b70.html

-------------------------------------------------------------------------------------------------------------------------------------------

 

XML Web Service支持三種協議來與用戶交流數據。這三種協議分別是：

1． SOAP：Simple Object Access Protocol

2．  HTTP-GET

3．   HTTP-POST

1．首先咱們先來理解一下這三者的大概定義。

在這三種協議中，SOAP是XML Web Service最經常使用到的鏈接協議。與HTTP相比，SOAP顯的更爲複雜，但卻擁有更強的接受能力。SOAP是一種以XML爲基礎的協議，它提供一種將數據打包（Packaging）和 編碼（Encoding）的方法，以用於網絡的數據傳輸。任意一個用戶均可以使用SOAP協議與任何一個XML Web Service進行通訊，甚至於說這個XML Web Service不是創建在.NET 平臺上的，好比說Java的，咱們均可以利用SOAP來進行數據傳輸。所以可見，SOAP也是Language Independent.(語言獨立性)

HTTP(Hypertext Transfer Protocol) 已是衆所周知的協議了，它是XML Web Service數據傳輸的標準，這包括了在使用SOAP傳輸數據的時候。HTTP將SOAP 消息壓縮,而後以它的形式進行網絡傳輸。然而當咱們談及在XML Web Service下使用HTTP-GET和HTTP-POST的時候，咱們實事上在談有關單獨使用HTTP調用XML Web Service中的方法的能力，這裏我說的單獨使用，指的是不使用SOAP。

在HTTP中，GET 和　POST並非一種協議，它們是能夠用來與Web Service交互的幾種方法中的其中二種。然而，這二種方法的傳送參數和數據的能力使它們變成了一種簡單的，很是適合用來調用XML Web Service的工具。

 

2．HTTP-GET 和　HTTP-POST 的比較

這兩者最大的區別在於數據是如何與要求的消息捆綁在一塊兒的。

HTTP-GET的處理特徵以下：

。將數據添加到URL

。利用一個問號（」?」）表明URL地址的結尾與數據的開端。

。每個數據的元素以 名稱/值 (name/value)　的形式出現。

。利用一個分號(「;」)來區分多個數據元素。

HTTP-POST的處理特徵以下：

。將數據包括在HTTP主體中。

。一樣的，數據的元素以 名稱/值 (name/value)　的形式出現。

。可是每個數據元素分別佔用主體的一行。

從這兩者不一樣的處理特徵，能夠看出它們的不一樣之處，而你們也能夠利用IE打開一個Web Service文件，在頁面中，IE會顯示出二種的數據的不一樣之處。

3．HTTP和SOAP的比較

HTTP-GET 和 HTTP-POST 提供了一個簡單的與XML Web Service交互的工具，與SOAP相比，它有如下幾點好處：

。 可以很是容易的建立正確的HTTP-GET 和 HTTP-POST消息，當面向的客戶是不能使用SOAP的客戶時，HTTP-GET 和 HTTP-POST是最好的選擇。

。響應HTTP-GET 和 HTTP-POST的消息，並不須要複雜的XML處理。響應之中包括了XML，但它有一個簡單的框架並可以輕易的利用通常的技術處理響應。這些特色使HTTP-GET 和 HTTP-POST對於不支持XML的平臺來講，變的異常的有用。

。HTTP-GET 和 HTTP-POST消息比起SOAP消息來講，更爲簡單。這有利於提升總體的性能。

然而，有得必有失，有好必有壞，它們也存在不可忽略的缺點：

。不可以利用HTML調用XML Web Service中的以複雜數據類型爲參數的方法。

。你能夠調用XML Web Service中返回值爲複雜數據類型的方法，可是響應將僅包括複雜數據類型中各個區域中的名字/值，而且返回的值並無結構可言。你必須手動的將數據解壓縮到WSDL文件。

。在HTTP中，你不能使用reference進行參數的傳輸。

。使用HTTP與XML Web Service進行交流，不是一個agreed-to工業標準技術。雖然HTTP會在ASP.NET Web Application中與XML Web Service正常工做，但不保證它在其它的環境下正常工做。

 

 

 

 

 

 

現在，Web開發者的可選技術至關之多；從簡化的數據庫訪問技術，到易用的中間件服務包裝技術，以及各類有趣的客戶端軟件等等，包羅萬象。全部這些產品和工具，都是爲了幫助Web開發者用最快的速度開發出最好的Web應用。

 

然而，擁有大量可選軟件方案以及爲Web應用的特定部分選用特定方案，都是具備挑戰的事；並且，如今Web開發者必須持續跟蹤各類不斷變化着的標準與方法。

 

舉個例子，Web服務技術就有SOAP（Simple Object Access Protocol，簡單對象訪問協議）和REST（Representational State Transfer，表示性狀態轉移）這兩種方案。它們都是有效的方案，但在具體場合下采用哪一種方案好，這要取決於Web開發者。

 

目前，大部分Web開發者彷佛都瞭解REST——一種採用標準URI進行調用的方案。REST很容易理解，並且只要是支持HTTP/HTTPS的客戶端/服務器就支持它。你能夠用HTTP GET方法來執行命令。因此，開發者們感覺到的REST的優點是：開發簡單、只需依託現有Web基礎設施、以及學習成本低。

然而，SOAP做爲一種古老的Web服務技術，短時間內還不會退出歷史舞臺。並且，隨着SOAP 1.2的出現，SOAP印象中的一些缺點已獲得改進，採納率和易用程度也都獲得提升。另需注意的是，從W3C SOAP 1.2版開始，SOAP這一縮寫再也不表明Simple Object Access Protocol（簡單對象訪問協議），而是僅僅做爲協議名稱而已。

 

相對REST而言，SOAP 1.2多出一些開銷，不過這些開銷也帶來了一些好處。首先，SOAP在三個方面離不開XML（Extensible Markup Language，可擴展標記語言）：SOAP信封（envelope）是基於XML的，它定義了消息裏有什麼以及如何處理它；一套用於數據類型的編碼規則；過程調用和響應的規劃。SOAP信封由傳輸協議（HTTP/HTTPS）發出，RPC（Remote Procedure Call，遠程過程調用）獲得執行，而後一個XML文檔隨SOAP信封返回。

 

須要注意的是，基於「通用」傳輸協議是SOAP的一個優勢。REST目前基於HTTP/HTTPS；而SOAP可支持任何傳輸協議，從HTTP/HTTPS到SMTP（Simple Mail Transfer Protocol，簡單郵件傳送協議），甚至JMS（Java Messaging Service，Java消息傳遞服務）。不過，因爲XML較爲冗長且解析費時，所以採用XML也成爲一個弊端。

不過，對Web開發者來講的好消息是，目前上述兩種方案都是行之有效的方案。REST和SOAP都能解決許多Web方面的問題與挑戰，並且在許多狀況下，它們各自都能知足開發者的要求，也就是說可互換使用。

但不少人不知道，這兩種技術能夠混合搭配使用。REST很好理解，且極易上手；不過因爲它缺少標準，所以只被看做是一種架構方法。與之相比，SOAP是一個工業標準，它具有良好定義的協議，以及一套良好確立的規則，在大型和小型系統中均有采用。

所以，REST的適用場合包括：

• 有限的帶寬和資源 別忘了返回的結構能夠採用（由開發者定義的）任何格式。另外，因爲REST採用標準的GET、PUT、POST和DELETE動詞，所以可被任何瀏覽器所支持。除此之外，REST還可使用爲目前大多數瀏覽器支持的XMLHttpRequest對象，這爲AJAX增色很多。
• 徹底無狀態的操做 對於那些需多步執行的操做，REST並不是最佳選擇，採用SOAP更合適。可是，若是你須要無狀態的CRUD（Create/Read/Update/Delete，建立/讀取/更新/刪除）操做，那麼應採用REST。
• 緩存考慮 若要利用無狀態操做的特性，使得信息可被緩存，那麼REST是很好的選擇。

以上已經覆蓋不少方案了，那麼，爲何還要考慮SOAP呢？正如前述，SOAP比較成熟並且是通過良好定義的，具備完整的規範。而REST只不過是一種方法，對開發未做任何規約；所以，假如你遇到如下場合，那麼SOAP是最佳選擇：

• 異步處理與調用 若是你的應用須要確保可靠性與安全性，那麼請採用SOAP。SOAP 1.2爲確保這種操做補充定義了WSRM（WS-Reliable Messaging）等標準。
• 形式化契約 若提供者/消費者雙方必須就交換格式取得一致，那麼採用SOAP更合適。SOAP 1.2爲這種交互提供了嚴格的規範。
• 有狀態的操做 若是應用須要上下文信息與對話狀態管理，那麼應採用SOAP。SOAP 1.2爲此補充定義了WS-Security、WS-Transactions和WS-Coordination等標準。相比之下，REST方法要求開發者本身來實現這些框架性工做。

正如你所看到的，REST和SOAP各自有其用武之地。它們在安全性和傳輸層等方面有着本身的潛在問題，不過它們都能完成任務，並且在許多狀況下，它們都豐富了Web的技術手段。所以，就這一論題，其實最好的原則就是靈活性原則；由於至少在現今的Web開發中，不管面對何種問題，Web開發者們總有辦法運用好這兩種技術中的一種。