REST和SOAP Web Service的差別比較

 本文轉載自他人的部落格，ArcGIS Server 推出了 對 SOAP 和

REST兩種接口（用接口類型也許并不準确）類型的支援,本文非常清晰的比較了SOAP和Rest的差別聯系！

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

REST似乎在一夜間興起了，這可能引起一些争議，反對者可以說REST是WEB誕生之始甚而是HTTP出現之日就相伴而生的原則。但是毋庸置疑的事實是，在Google和Yahoo等網絡巨頭釋出的相同功能的Web

Service API中，REST無疑受到更多的青睐，是以是不是可以這樣說：RPC在一夜之間衰落了？

在一篇作業的小文章裡讨論整套RPC的原理，無疑太過龐大了，況且RPC在Web

Service領域的應用也無過XML-RPC以及由此延伸的SOAP而已。在原理上唯一重要的，是傳統程式的函數調用和傳回在RPC中被請求和應答代替了而已。既然如此，在讨論REST之前先闡述SOAP，可能是合乎邏輯的順序。

什麼是SOAP?

SOAP (Simple Object Access Protocol) 顧名思義，是一個嚴格定義的資訊交換協定，用于在Web

Service中把遠端調用和傳回封裝成機器可讀的格式化資料。事實上SOAP資料使用XML資料格式，定義了一整套複雜的标簽，以描述調用的遠端過程、參數、傳回值和出錯資訊等等。而且随着需要的增長，又不得增加協定以支援安全性，這使SOAP變得異常龐大，背離了簡單的初衷。另一方面，各個伺服器都可以基于這個協定推出自己的API，即使它們提供的服務及其相似，定義的API也不盡相同，這又導緻了WSDL的誕生。WSDL

(Web Service Description Language)

也遵循XML格式，用來描述哪個伺服器提供什麼服務，怎樣找到它，以及該服務使用怎樣的接口規範，簡言之，服務發現。現在，使用Web

Service的過程變成，獲得該服務的WSDL描述，根據WSDL構造一條格式化的SOAP請求發送給伺服器，然後接收一條同樣SOAP格式的應答，最後根據先前的WSDL解碼資料。絕大多數情況下，請求和應答使用HTTP協定傳輸，那麼發送請求就使用HTTP的POST方法。

什麼是REST？

REST (REpresentational State Transfort)

形式上應該表述為用戶端通過申請資源來實作狀态的轉換，在這個角度系統可以看成一台虛拟的狀态機。抛開R. T.

Fielding博士論文裡晦澀的理論不說，REST應該滿足這樣的特點：

1)用戶端和伺服器結構；

2)連接配接協定具有無狀态性；

3)能夠利用Cache機制增進性能；

4)階層化的系統；

5)按需代碼。

說到底，REST隻是一種架構風格，而不是協定或标準。但這種新的風格（也許已經曆史悠久？）對現有的以SOAP為代表的Web

Service造成的沖擊也是革命性的，因為它面向資源，甚至連服務也抽象成資源，因為它和HTTP緊密結合，因為它伺服器無狀态。

REST與SOAP的差別

因為SOAP并不假定傳輸資料的下層協定，是以必須設計為能在各種協定上運作。即使絕大多數SOAP是運作在HTTP上，使用URI辨別服務，SOAP也僅僅使用POST方法發送請求，用一個唯一的URI辨別服務的入口。

舉一個圖書館線上查詢管理系統為例，服務提供者必須為每一本書提供一個内部辨別，然後可能定義一個listBooks操作來傳回一系列圖書，一個getBook操作來傳回指定的圖書，一個createBook操作來向資料庫加入新增的圖書，一個deleteBook操作來删除廢棄的圖書，每個操作都有各自的參數，尤其是用内部辨別來辨別操作的圖書。這種設計被诟病之處，在于deleteBook操作也要用POST方法來發送，而其實HTTP協定有更和邏輯的DELETE方法可用。REST正是這樣設計的，REST為每一個資源（此處是圖書）指定一個唯一的URI，而用HTTP的4種方法GET、POST、PUT、DELETE直覺地表示擷取、建立、更新和删除圖書。同時圖書集合也是和單本的圖書不同的資源，如果用/books來代表圖書清單，/books/ID來代表辨別為ID的圖書，那麼對/books的GET操作就代表傳回整個圖書清單，對/books/ID的DELETE操作代表删除指定的圖書，等等。

REST的優點

REST簡單而直覺，把HTTP協定利用到了極限，在這種思想指導下，它甚至用HTTP請求的頭資訊來指明資源的表示形式（如果一個資源有多種形式的話，例如人類友善的頁面還是機器可讀的資料？），用HTTP的錯誤機制來傳回通路資源的錯誤。由此帶來的直接好處是建構的成本減少了，例如用URI定位每一個資源可以利用通用成熟的技術，而不用再在伺服器端開發一套資源通路機制。又如隻需簡單配置伺服器就能規定資源的通路權限，例如通過禁止非GET通路把資源設成隻讀。

伺服器無狀态帶來了更多額外好處，因為每次請求都包含響應需要的所有資訊，所有狀态資訊都存儲在用戶端，伺服器的記憶體從龐大的狀态資訊中解放出來。而且現在即使一台伺服器突然當機對客戶的影響也微乎其微，因為另一台伺服器可以馬上代替它的位置，而不需要考慮恢複狀态資訊。更多的緩存也變成可能，而之前由于伺服器有狀态，對同一個URI的請求可能導緻完全不同的響應。

總體結果是，網絡的容錯性和延展性都增強了，這些本來是WEB設計的初衷，日趨複雜和定制的WEB把它們破壞了，現在REST又返璞歸真，試圖把Web

Service帶回簡單的原則中來。

REST是萬能的嗎？

但是REST就是萬能的嗎？無狀态帶來了巨大的優勢，同時也帶來了難以解決的問題，例如，怎樣授權特定使用者才能使用的服務？怎樣驗證使用者身份？如果堅持伺服器無狀态，也就是不記錄使用者登入狀态，勢必要求每一次服務請求都包含完整的使用者身份和驗證資訊。在這種情況下，怎樣避免冒認？怎樣避免使用者資訊洩漏？事實上，建構REST附屬的安全機制已經在讨論中，其結果無非導緻另一個SOAP：複雜的需求摧殘了易用性。

REST的支援者聲稱REST的請求和應答資料簡單可讀，而SOAP則需要一系列繁瑣的封裝；即使如此，SOAP仍然不能達到接口的一緻性，不同的廠商有各自的接口，而REST隻使用HTTP定義的方法，是以是通用的。事實确實如此嗎？試想用REST實作兩數求和的服務，如果按照建議的做法，把服務（此處是加法）作為一個資源，參數（此處是兩個加數）作為請求的參數，結果以XML或JSON文法傳回，是否比SOAP更簡單易用？通用接口仍然沒法達到，因為資源的名稱、參數的名稱、結果的格式仍然是服務提供者定義的。

為了解決這個問題，提出了WASL(Web Application Description

Language)來描述REST接口。WADL就像是WSDL的REST版，随着REST被應用到複雜的領域，SOAP的影子無處不在。

面向資源和面向事務（非常明顯的說明了Rest的試用範圍，請求地圖資料就可以認為主要是請求一種特殊的資源）

REST在面向資源的應用中左右逢源，但在面向事務的應用中卻未如人意。面向資源的應用操作簡單，無非建立、讀取、改變、删除幾項，但是面向事務的應用不允許使用者直接操作資源，使用者隻需向系統送出一個事務說明要求，然後等待事務的完成，就如一個網上銀行的使用者不直接修改賬戶和存款，而是送出一個事務告訴銀行自己要轉賬。如果把這樣的服務看成一種資源，通過向資源發送POST請求完成事務，那不過是SOAP的翻版而已，無論是這樣，還是通過PUT來建立事務，都改變了系統的狀态（資源本身未改變，此處是改變了使用者的餘額），顯然違背了REST直覺的初衷。

事實上，一些Web Service提供者提供的REST

API隻有REST的外殼，傳輸的請求和應答全然是簡化了的SOAP，這種新瓶裝舊酒的做法隻是加深了标準的分歧而已。歸根結底REST無法簡單地解決一些應用，是以我們隻能看到SOAP在REST外殼下的借屍還魂。沒有一項技術能一勞永逸地解決所有問題，隻需要在預定的限制下優美地解決所在領域的問題就足夠了。一項新技術推出的時候總是引來無數的跟風和吹捧，隻有當塵埃落定之後才能得到中肯的評價。