http://www.360doc.com/content/12/0530/17/1369263_214781509.shtml

?

在SOA的基礎(chǔ)技術(shù)實現(xiàn)方式中WebService占據(jù)了很重要的地位，通常我們提到WebService第一想法就是SOAP消息在各種傳輸協(xié)議上交互。近幾年REST的思想伴隨著SOA逐漸被大家接受，同時各大網(wǎng)站不斷開放API提供給開發(fā)者，也激起了REST風(fēng)格WebService的熱潮。

SOAP

?????? 什么是SOAP，我想不用多說，google一把滿眼都是。其實SOAP最早是針對RPC的一種解決方案，簡單對象訪問協(xié)議，很輕量，同時作為應(yīng)用協(xié)議可以基于多種傳輸協(xié)議來傳遞消息（Http,SMTP等）。但是隨著SOAP作為WebService的廣泛應(yīng)用，不斷地增加附加的內(nèi)容，使得現(xiàn)在開發(fā)人員覺得SOAP很重，使用門檻很高。在SOAP后續(xù)的發(fā)展過程中，WS-*一系列協(xié)議的制定，增加了SOAP的成熟度，也給SOAP增加了負擔(dān)。

REST

?????? REST其實并不是什么協(xié)議也不是什么標(biāo)準(zhǔn)，而是將Http協(xié)議的設(shè)計初衷作了詮釋，在Http協(xié)議被廣泛利用的今天，越來越多的是將其作為傳輸協(xié)議，而非原先設(shè)計者所考慮的應(yīng)用協(xié)議。SOAP類型的WebService就是最好的例子，SOAP消息完全就是將Http協(xié)議作為消息承載，以至于對于Http協(xié)議中的各種參數(shù)（例如編碼，錯誤碼等）都置之不顧。其實，最輕量級的應(yīng)用協(xié)議就是Http協(xié)議。Http協(xié)議所抽象的get,post,put,delete就好比數(shù)據(jù)庫中最基本的增刪改查，而互聯(lián)網(wǎng)上的各種資源就好比數(shù)據(jù)庫中的記錄（可能這么比喻不是很好），對于各種資源的操作最后總是能抽象成為這四種基本操作，在定義了定位資源的規(guī)則以后，對于資源的操作通過標(biāo)準(zhǔn)的Http協(xié)議就可以實現(xiàn)，開發(fā)者也會受益于這種輕量級的協(xié)議。

??? REST的思想歸結(jié)以下有如下幾個關(guān)鍵點：

1．面向資源的接口設(shè)計

所有的接口設(shè)計都是針對資源來設(shè)計的，也就很類似于我們的面向?qū)ο蠛兔嫦蜻^程的設(shè)計區(qū)別，只不過現(xiàn)在將網(wǎng)絡(luò)上的操作實體都作為資源來看待，同時URI的設(shè)計也是體現(xiàn)了對于資源的定位設(shè)計。后面會提到有一些網(wǎng)站的API設(shè)計說是REST設(shè)計，其實是RPC-REST的混合體，并非是REST的思想。

?????? 2．抽象操作為基礎(chǔ)的CRUD

?????? 這點很簡單，Http中的get,put,post,delete分別對應(yīng)了read,update,create,delete四種操作，如果僅僅是作為對于資源的操作，抽象成為這四種已經(jīng)足夠了，但是對于現(xiàn)在的一些復(fù)雜的業(yè)務(wù)服務(wù)接口設(shè)計，可能這樣的抽象未必能夠滿足。其實這也在后面的幾個網(wǎng)站的API設(shè)計中暴露了這樣的問題，如果要完全按照REST的思想來設(shè)計，那么適用的環(huán)境將會有限制，而非放之四海皆準(zhǔn)的。??????

?????? 3．Http是應(yīng)用協(xié)議而非傳輸協(xié)議

?????? 這點在后面各大網(wǎng)站的API分析中有很明顯的體現(xiàn)，其實有些網(wǎng)站已經(jīng)走到了SOAP的老路上，說是REST的理念設(shè)計，其實是作了一套私有的SOAP協(xié)議，因此稱之為REST風(fēng)格的自定義SOAP協(xié)議。

4．無狀態(tài)，自包含

這點其實不僅僅是對于REST來說的，作為接口設(shè)計都需要能夠做到這點，也是作為可擴展和高效性的最基本的保證，就算是使用SOAP的WebService也是一樣。

REST vs SOAP

成熟度：

SOAP雖然發(fā)展到現(xiàn)在已經(jīng)脫離了初衷，但是對于異構(gòu)環(huán)境服務(wù)發(fā)布和調(diào)用，以及廠商的支持都已經(jīng)達到了較為成熟的情況。不同平臺，開發(fā)語言之間通過SOAP來交互的web service都能夠較好的互通（在部分復(fù)雜和特殊的參數(shù)和返回對象解析上，協(xié)議沒有作很細致的規(guī)定，導(dǎo)致還是需要作部分修正）

REST國外很多大網(wǎng)站都發(fā)布了自己的開發(fā)API，很多都提供了SOAP和REST兩種Web Service，根據(jù)調(diào)查部分網(wǎng)站的REST風(fēng)格的使用情況要高于SOAP。但是由于REST只是一種基于Http協(xié)議實現(xiàn)資源操作的思想，因此各個網(wǎng)站的REST實現(xiàn)都自有一套，在后面會講訴各個大網(wǎng)站的REST API的風(fēng)格。也正是因為這種各自實現(xiàn)的情況，在性能和可用性上會大大高于SOAP發(fā)布的web service，但統(tǒng)一通用方面遠遠不及SOAP。由于這些大網(wǎng)站的SP往往專注于此網(wǎng)站的API開發(fā)，因此通用性要求不高。

由于沒有類似于SOAP的權(quán)威性協(xié)議作為規(guī)范，REST實現(xiàn)的各種協(xié)議僅僅只能算是私有協(xié)議，當(dāng)然需要遵循REST的思想，但是這樣細節(jié)方面有太多沒有約束的地方。REST日后的發(fā)展所走向規(guī)范也會直接影響到這部分的設(shè)計是否能夠有很好的生命力。

總的來說SOAP在成熟度上優(yōu)于REST。

效率和易用性：

?????? SOAP協(xié)議對于消息體和消息頭都有定義，同時消息頭的可擴展性為各種互聯(lián)網(wǎng)的標(biāo)準(zhǔn)提供了擴展的基礎(chǔ)，WS-*系列就是較為成功的規(guī)范。但是也由于SOAP由于各種需求不斷擴充其本身協(xié)議的內(nèi)容，導(dǎo)致在SOAP處理方面的性能有所下降。同時在易用性方面以及學(xué)習(xí)成本上也有所增加。

?????? REST被人們的重視，其實很大一方面也是因為其高效以及簡潔易用的特性。這種高效一方面源于其面向資源接口設(shè)計以及操作抽象簡化了開發(fā)者的不良設(shè)計，同時也最大限度的利用了Http最初的應(yīng)用協(xié)議設(shè)計理念。同時，在我看來REST還有一個很吸引開發(fā)者的就是能夠很好的融合當(dāng)前Web2.0的很多前端技術(shù)來提高開發(fā)效率。例如很多大型網(wǎng)站開放的REST風(fēng)格的API都會有多種返回形式，除了傳統(tǒng)的xml作為數(shù)據(jù)承載，還有（JSON,RSS,ATOM）等形式，這對很多網(wǎng)站前端開發(fā)人員來說就能夠很好的mashup各種資源信息。

?????? 因此在效率和易用性上來說，REST更勝一籌。

安全性：

?????? 這點其實可以放入到成熟度中，不過在當(dāng)前的互聯(lián)網(wǎng)應(yīng)用和平臺開發(fā)設(shè)計過程中，安全已經(jīng)被提到了很高的高度，特別是作為外部接口給第三方調(diào)用，安全性可能會高過業(yè)務(wù)邏輯本身。

?????? SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規(guī)范組成了WS-Security來實現(xiàn)安全控制的，當(dāng)前已經(jīng)得到了各個廠商的支持，.net ，php ，java 都已經(jīng)對其有了很好的支持（雖然在一些細節(jié)上還是有不兼容的問題，但是互通基本上是可以的）。

?????? REST沒有任何規(guī)范對于安全方面作說明，同時現(xiàn)在開放REST風(fēng)格API的網(wǎng)站主要分成兩種，一種是自定義了安全信息封裝在消息中（其實這和SOAP沒有什么區(qū)別），另外一種就是靠硬件SSL來保障,但是這只能夠保證點到點的安全，如果是需要多點傳輸?shù)脑扴SL就無能為力了。安全這塊其實也是一個很大的問題，今年在BEA峰會上看到有演示采用SAML2實現(xiàn)的網(wǎng)站間SSO，其實是直接采用了XML-Security和XML-Signature，效率看起來也不是很高。未來REST規(guī)范化和通用化過程中的安全是否也會采用這兩種規(guī)范，是未知的，但是加入的越多，REST失去它高效性的優(yōu)勢越多。

應(yīng)用設(shè)計與改造：

?????? 我們的系統(tǒng)要么就是已經(jīng)有了那些需要被發(fā)布出去的服務(wù)，要么就是剛剛設(shè)計好的服務(wù)，但是開發(fā)人員的傳統(tǒng)設(shè)計思想讓REST的形式被接受還需要一點時間。同時在資源型數(shù)據(jù)服務(wù)接口設(shè)計上來說按照REST的思想來設(shè)計相對來說要容易一些，而對于一些復(fù)雜的服務(wù)接口來說，可能強要去按照REST的風(fēng)格來設(shè)計會有些牽強。這一點其實可以看看各大網(wǎng)站的接口就可以知道，很多網(wǎng)站還要傳入function的名稱作為參數(shù)，這就明顯已經(jīng)違背了REST本身的設(shè)計思路。

?????? 而SOAP本身就是面向RPC來設(shè)計的，開發(fā)人員十分容易接受，所以不存在什么適應(yīng)的過程。

總的來說，其實還是一個老觀念，適合的才是最好的

?????? 技術(shù)沒有好壞，只有是不是合適，一種好的技術(shù)和思想被誤用了，那么就會得到反效果。REST和SOAP各自都有自己的優(yōu)點，同時如果在一些場景下如果去改造REST，其實就會走向SOAP（例如安全）。

?????? REST對于資源型服務(wù)接口來說很合適，同時特別適合對于效率要求很高，但是對于安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發(fā)語言的，對于安全性要求較高的接口設(shè)計帶來便利。所以我覺得純粹說什么設(shè)計模式將會占據(jù)主導(dǎo)地位沒有什么意義，關(guān)鍵還是看應(yīng)用場景。

?????? 同時很重要一點就是不要扭曲了REST現(xiàn)在很多網(wǎng)站都跟風(fēng)去開發(fā)REST風(fēng)格的接口，其實都是在學(xué)其形，不知其心，最后弄得不倫不類，性能上不去，安全又保證不了，徒有一個看似象摸象樣的皮囊。

?

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

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

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