??今天遇到一個webservice協(xié)議的接口需求，在使用soupUI測試接口連通性的時候，發(fā)現(xiàn)使用soupUI新建一個SOAP項目的時候，WSDL鏈接總是報錯打不開（廠家提供的接口規(guī)范上寫的是SOAP協(xié)議），但是使用瀏覽器訪問，可以看到WSDL文件，這就說明WSDL地址沒有問題。后來我換了一種方式，新建了一個REST項目，鏈接正常打開。之前也遇到過類似的問題，也學(xué)習(xí)了一些SOAP協(xié)議和REST協(xié)議，但是總是感覺沒有理解透徹，今天在刷網(wǎng)頁時偶然間看到一篇博客，把SOAP和REST的webservice講解的很清楚，有一種恍然大悟的感覺。摘錄如下：


?? REST似乎在一夜間興起了，這可能引起一些爭議，反對者可以說REST是WEB誕生之始甚而是HTTP出現(xiàn)之日就相伴而生的原則。但是毋庸置疑的事實(shí)是，在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) 顧名思義，是一個嚴(yán)格定義的信息交換協(xié)議，用于在Web Service中把遠(yuǎn)程調(diào)用和返回封裝成機(jī)器可讀的格式化數(shù)據(jù)。事實(shí)上SOAP數(shù)據(jù)使用XML數(shù)據(jù)格式，定義了一整套復(fù)雜的標(biāo)簽，以描述調(diào)用的遠(yuǎn)程過程、參數(shù)、返回值和出錯信息等等。而且隨著需要的增長，又不得增加協(xié)議以支持安全性，這使SOAP變得異常龐大，背離了簡單的初衷。另一方面，各個服務(wù)器都可以基于這個協(xié)議推出自己的API，即使它們提供的服務(wù)及其相似，定義的API也不盡相同，這又導(dǎo)致了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)該表述為客戶端通過申請資源來實(shí)現(xiàn)狀態(tài)的轉(zhuǎn)換，在這個角度系統(tǒng)可以看成一臺虛擬的狀態(tài)機(jī)。拋開R. T. Fielding博士論文里晦澀的理論不說，REST應(yīng)該滿足這樣的特點(diǎn)：

1)客戶端和服務(wù)器結(jié)構(gòu)；
2)連接協(xié)議具有無狀態(tài)性；
3)能夠利用Cache機(jī)制增進(jìn)性能；
4)層次化的系統(tǒng)；
5)按需代碼。

?? 說到底，REST只是一種架構(gòu)風(fēng)格，而不是協(xié)議或標(biāo)準(zhǔn)。但這種新的風(fēng)格（也許已經(jīng)歷史悠久？）對現(xiàn)有的以SOAP為代表的Web Service造成的沖擊也是革命性的，因?yàn)樗嫦蛸Y源，甚至連服務(wù)也抽象成資源，因?yàn)樗虷TTP緊密結(jié)合，因?yàn)樗?wù)器無狀態(tài)。


REST與SOAP的區(qū)別
?? 因?yàn)镾OAP并不假定傳輸數(shù)據(jù)的下層協(xié)議，因此必須設(shè)計為能在各種協(xié)議上運(yùn)行。即使絕大多數(shù)SOAP是運(yùn)行在HTTP上，使用URI標(biāo)識服務(wù)，SOAP也僅僅使用POST方法發(fā)送請求，用一個唯一的URI標(biāo)識服務(wù)的入口。


?? 舉一個圖書館在線查詢管理系統(tǒng)為例，服務(wù)提供者必須為每一本書提供一個內(nèi)部標(biāo)識，然后可能定義一個listBooks操作來返回一系列圖書，一個getBook操作來返回指定的圖書，一個createBook操作來向數(shù)據(jù)庫加入新增的圖書，一個deleteBook操作來刪除作廢的圖書，每個操作都有各自的參數(shù)，尤其是用內(nèi)部標(biāo)識來標(biāo)識操作的圖書。這種設(shè)計被詬病之處，在于deleteBook操作也要用POST方法來發(fā)送，而其實(shí)HTTP協(xié)議有更和邏輯的DELETE方法可用。REST正是這樣設(shè)計的，REST為每一個資源（此處是圖書）指定一個唯一的URI，而用HTTP的4種方法GET、POST、PUT、DELETE直觀地表示獲取、創(chuàng)建、更新和刪除圖書。同時圖書集合也是和單本的圖書不同的資源，如果用/books來代表圖書列表，/books/ID來代表標(biāo)識為ID的圖書，那么對/books的GET操作就代表返回整個圖書列表，對/books/ID的DELETE操作代表刪除指定的圖書，等等。


REST的優(yōu)點(diǎn)
?? REST簡單而直觀，把HTTP協(xié)議利用到了極限，在這種思想指導(dǎo)下，它甚至用HTTP請求的頭信息來指明資源的表示形式（如果一個資源有多種形式的話，例如人類友善的頁面還是機(jī)器可讀的數(shù)據(jù)？），用HTTP的錯誤機(jī)制來返回訪問資源的錯誤。由此帶來的直接好處是構(gòu)建的成本減少了，例如用URI定位每一個資源可以利用通用成熟的技術(shù)，而不用再在服務(wù)器端開發(fā)一套資源訪問機(jī)制。又如只需簡單配置服務(wù)器就能規(guī)定資源的訪問權(quán)限，例如通過禁止非GET訪問把資源設(shè)成只讀。
?? 服務(wù)器無狀態(tài)帶來了更多額外好處，因?yàn)槊看握埱蠖及憫?yīng)需要的所有信息，所有狀態(tài)信息都存儲在客戶端，服務(wù)器的內(nèi)存從龐大的狀態(tài)信息中解放出來。而且現(xiàn)在即使一臺服務(wù)器突然死機(jī)對客戶的影響也微乎其微，因?yàn)榱硪慌_服務(wù)器可以馬上代替它的位置，而不需要考慮恢復(fù)狀態(tài)信息。更多的緩存也變成可能，而之前由于服務(wù)器有狀態(tài)，對同一個URI的請求可能導(dǎo)致完全不同的響應(yīng)。
?? 總體結(jié)果是，網(wǎng)絡(luò)的容錯性和延展性都增強(qiáng)了，這些本來是WEB設(shè)計的初衷，日趨復(fù)雜和定制的WEB把它們破壞了，現(xiàn)在REST又返璞歸真，試圖把Web Service帶回簡單的原則中來。


REST是萬能的嗎？
??但是REST就是萬能的嗎？無狀態(tài)帶來了巨大的優(yōu)勢，同時也帶來了難以解決的問題，例如，怎樣授權(quán)特定用戶才能使用的服務(wù)？怎樣驗(yàn)證用戶身份？如果堅持服務(wù)器無狀態(tài)，也就是不記錄用戶登錄狀態(tài)，勢必要求每一次服務(wù)請求都包含完整的用戶身份和驗(yàn)證信息。在這種情況下，怎樣避免冒認(rèn)？怎樣避免用戶信息泄漏？事實(shí)上，構(gòu)建REST附屬的安全機(jī)制已經(jīng)在討論中，其結(jié)果無非導(dǎo)致另一個SOAP：復(fù)雜的需求摧殘了易用性。
??REST的支持者聲稱REST的請求和應(yīng)答數(shù)據(jù)簡單可讀，而SOAP則需要一系列繁瑣的封裝；即使如此，SOAP仍然不能達(dá)到接口的一致性，不同的廠商有各自的接口，而REST只使用HTTP定義的方法，因此是通用的。事實(shí)確實(shí)如此嗎？試想用REST實(shí)現(xiàn)兩數(shù)求和的服務(wù)，如果按照建議的做法，把服務(wù)（此處是加法）作為一個資源，參數(shù)（此處是兩個加數(shù)）作為請求的參數(shù)，結(jié)果以XML或JSON語法返回，是否比SOAP更簡單易用？通用接口仍然沒法達(dá)到，因?yàn)橘Y源的名稱、參數(shù)的名稱、結(jié)果的格式仍然是服務(wù)提供者定義的。
?? 為了解決這個問題，提出了WASL(Web Application Description Language)來描述REST接口。WADL就像是WSDL的REST版，隨著REST被應(yīng)用到復(fù)雜的領(lǐng)域，SOAP的影子無處不在。
?? 面向資源和面向事務(wù)（非常明顯的說明了Rest的試用范圍，請求地圖數(shù)據(jù)就可以認(rèn)為主要是請求一種特殊的資源）


?? 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直觀的初衷。
?? 事實(shí)上，一些Web Service提供者提供的REST API只有REST的外殼，傳輸?shù)恼埱蠛蛻?yīng)答全然是簡化了的SOAP，這種新瓶裝舊酒的做法只是加深了標(biāo)準(zhǔn)的分歧而已。歸根結(jié)底REST無法簡單地解決一些應(yīng)用，因此我們只能看到SOAP在REST外殼下的借尸還魂。沒有一項技術(shù)能一勞永逸地解決所有問題，只需要在預(yù)定的約束下優(yōu)美地解決所在領(lǐng)域的問題就足夠了。一項新技術(shù)推出的時候總是引來無數(shù)的跟風(fēng)和吹捧，只有當(dāng)塵埃落定之后才能得到中肯的評價。

總結(jié)

以上是生活随笔為你收集整理的【REST SOAP】REST和SOAP Web Service的区别比较的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。