WebService SOAP XML 與 REST JSON 架構的比較
一般客戶端訪問伺服器端web服務通常可以由HTTPService、WebService、RemoteObject等方式來實現。通常實現web服務我們最容易想到的是SOAP協議的WebService，這在目前web服務中佔有很重要的地位。隨著REST思想的出現，目前很多公司開始使用REST風格的WebService。SOAP： 簡單物件訪問協議，簡單物件訪問協議（SOAP）是一種輕量的、簡單的、基於 XML 的協議，它被設計成在 WEB 上交換結構化的和固化的資訊。 SOAP 可以和現存的許多因特網協議和格式結合使用，包括超文字傳輸協議（ HTTP），簡單郵件傳輸協議（SMTP），多用途網際郵件擴充協議（MIME）。它還支援從訊息系統到遠端過程呼叫（RPC）等大量的應用程式。
REST: 即REST(Representational State Transfer表述性狀態轉移)是一種針對網路應用的設計和開發方式，可以降低開發的複雜性，提高系統的可伸縮性。
REST 與SOAP的比較：
成熟度
SOAP目前成熟，不同平臺，開發語言之間通過SOAP來互動的web service都能夠較好的互通。REST相對不太成熟，由於沒有類似於SOAP的權威性協議作為規範，REST實現的各種服務風格不一，通用性不強。
效率和易用性
SOAP使用門檻高（學習成本高，開發難度大），由於SOAP由於各種需求不斷擴充其本身協議的內容，在大併發下效能有所下降。REST 目前大量的Web 2.0網站使用，高效以及簡潔易用。這種高效一方面源於其面向資源介面設計以及操作抽象簡化了開發者的不良設計，同時也最大限度的利用了Http最初的應用協議設計理念。REST 是一種輕量級的Web Service架構風格，其實現和操作明顯比SOAP和XML-RPC更為簡潔，可以完全通過HTTP協議實現，還可以利用快取Cache來提高響應速度，效能、效率和易用性上都優於SOAP協議。
安全性
SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規範組成了WS-Security來實現安全控制的，當前已經得到了各個廠商的支援，.net ，php ，java 都已經對其有了很好的支援。REST沒有任何規範對於安全方面作說明。因此在考慮安全性上，SOAP要高於REST。
總的來說，我認為REST對於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而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(REpresentational State Transfort)形式上應該表述為客戶端通過申請資源來實現狀態的轉換，在這個角度系統可以看成一臺虛擬的狀態機。拋開R. T. Fielding博士論文裡晦澀的理論不說，REST應該滿足這樣的特點：
1.客戶端和伺服器結構
2.連線協議具有無狀態性
3.能夠利用Cache機制增進效能
4.層次化的系統
5.按需程式碼
說到底，REST只是一種架構風格，而不是協議或標準。但這種新的風格（也許已經歷史悠久？）對現有的以SOAP為代表的Web Service造成的衝擊也是革命性的，因為它面向資源，甚至連服務也抽象成資源，因為它和HTTP緊密結合，因為它伺服器無狀態。
因為SOAP並不假定傳輸資料的下層協議，因此必須設計為能在各種協議上執行。即使絕大多數SOAP是執行在HTTP上，使用URI標識服務，SOAP也僅僅使用POST方法傳送請求，用一個唯一的URI標識服務的入口。
REST簡單而直觀，把HTTP協議利用到了極限，在這種思想指導下，它甚至用HTTP請求的頭資訊來指明資源的表示形式（如果一個資源有多種形式的話，例如人類友善的頁面還是機器可讀的資料？），用HTTP的錯誤機制來返回訪問資源的錯誤。由此帶來的直接好處是構建的成本減少了，例如用URI定位每一個資源可以利用通用成熟的技術，而不用再在伺服器端開發一套資源訪問機制。又如只需簡單配置伺服器就能規定資源的訪問許可權，例如通過禁止非GET訪問把資源設成只讀。
伺服器無狀態帶來了更多額外好處，因為每次請求都包含響應需要的所有資訊，所有狀態資訊都儲存在客戶端，伺服器的記憶體從龐大的狀態資訊中解放出來。而且現在即使一臺伺服器突然宕機對客戶的影響也微乎其微，因為另一臺伺服器可以馬上代替它的位置，而不需要考慮恢復狀態資訊。更多的快取也變成可能，而之前由於伺服器有狀態，對同一個URI的請求可能導致完全不同的響應。
總體結果是，網路的容錯性和延展性都增強了，這些本來是WEB設計的初衷，日趨複雜和定製的WEB把它們破壞了，現在REST又返璞歸真，試圖把Web Service帶回簡單的原則中來。
但是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外殼下的借屍還魂。沒有一項技術能一勞永逸地解決所有問題，只需要在預定的約束下優美地解決所在領域的問題就足夠了。一項新技術推出的時候總是引來無數的跟風和吹捧，只有當塵埃落定之後才能得到中肯的評價。