国产亚洲美女精品久久久久狼,国产精品亚洲综合一区,亚洲最大的成人网

SOAP Webservice和RESTful Webservice

Refer to: http://blog.sina.com.cn/s/blog_493a845501012566.html

REST是一種架構(gòu)風(fēng)格，其核心是面向資源，REST專門針對(duì)網(wǎng)絡(luò)應(yīng)用設(shè)計(jì)和開發(fā)方式，以降低開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。REST提出設(shè)計(jì)概念和準(zhǔn)則為：

1.網(wǎng)絡(luò)上的所有事物都可以被抽象為資源(resource)
2.每一個(gè)資源都有唯一的資源標(biāo)識(shí)(resource identifier)，對(duì)資源的操作不會(huì)改變這些標(biāo)識(shí)
3.所有的操作都是無(wú)狀態(tài)的

REST簡(jiǎn)化開發(fā)，其架構(gòu)遵循CRUD原則，該原則告訴我們對(duì)于資源(包括網(wǎng)絡(luò)資源)只需要四種行為：創(chuàng)建，獲取，更新和刪除就可以完成相關(guān)的操作和處理。您可以通過(guò)統(tǒng)一資源標(biāo)識(shí)符（Universal Resource Identifier，URI）來(lái)識(shí)別和定位資源，并且針對(duì)這些資源而執(zhí)行的操作是通過(guò) HTTP 規(guī)范定義的。其核心操作只有GET,PUT,POST,DELETE。

由于REST強(qiáng)制所有的操作都必須是stateless的，這就沒有上下文的約束，如果做分布式，集群都不需要考慮上下文和會(huì)話保持的問(wèn)題。極大的提高系統(tǒng)的可伸縮性。

對(duì)于SOAP Webservice和Restful Webservice的選擇問(wèn)題，首先需要理解就是SOAP偏向于面向活動(dòng)，有嚴(yán)格的規(guī)范和標(biāo)準(zhǔn)，包括安全，事務(wù)等各個(gè)方面的內(nèi)容，同時(shí)SOAP強(qiáng)調(diào)操作方法和操作對(duì)象的分離，有WSDL文件規(guī)范和XSD文件分別對(duì)其定義。而REST強(qiáng)調(diào)面向資源，只要我們要操作的對(duì)象可以抽象為資源即可以使用REST架構(gòu)風(fēng)格。

如果從這個(gè)意義上講，是否使用REST就需要考慮資源本身的抽象和識(shí)別是否困難，如果本身就是簡(jiǎn)單的類似增刪改查的業(yè)務(wù)操作，那么抽象資源就比較容易，而對(duì)于復(fù)雜的業(yè)務(wù)活動(dòng)抽象資源并不是一個(gè)簡(jiǎn)單的事情。比如校驗(yàn)用戶等級(jí)，轉(zhuǎn)賬，事務(wù)處理等，這些往往并不容易簡(jiǎn)單的抽象為資源。

其次如果有嚴(yán)格的規(guī)范和標(biāo)準(zhǔn)定義要求，而且前期規(guī)范標(biāo)準(zhǔn)需要指導(dǎo)多個(gè)業(yè)務(wù)系統(tǒng)集成和開發(fā)的時(shí)候，SOAP風(fēng)格由于有清晰的規(guī)范標(biāo)準(zhǔn)定義是明顯有優(yōu)勢(shì)的。我們可以在開始和實(shí)現(xiàn)之前就嚴(yán)格定義相關(guān)的接口方法和接口傳輸數(shù)據(jù)。

簡(jiǎn)單數(shù)據(jù)操作，無(wú)事務(wù)處理，開發(fā)和調(diào)用簡(jiǎn)單這些是使用REST架構(gòu)風(fēng)格的優(yōu)勢(shì)。而對(duì)于較為復(fù)雜的面向活動(dòng)的服務(wù)，如果我們還是使用REST，很多時(shí)候都是仍然是傳統(tǒng)的面向活動(dòng)的思想通過(guò)轉(zhuǎn)換工具再轉(zhuǎn)換得到REST服務(wù)，這種使用方式是沒有意義的。

正如另外一篇文章里面談到的，REST核心是url和面向資源，url代替了原來(lái)復(fù)雜的操作方法。REST允許我們通過(guò)url設(shè)計(jì)系統(tǒng)，就像測(cè)試驅(qū)動(dòng)開發(fā)使用測(cè)試用例設(shè)計(jì)類接口一樣。所有可以被抽象為資源的東西都可以使用RESTful的url，當(dāng)我們以傳統(tǒng)的用SOAP方式實(shí)現(xiàn)的一個(gè)查詢訂單服務(wù)的時(shí)候可以看到，這個(gè)服務(wù)首先存在輸入的查詢條件，然后才是輸出結(jié)果集。那么對(duì)于類似場(chǎng)景要使用REST，不可避免的會(huì)將傳統(tǒng)的SOAP服務(wù)拆分為一個(gè)HTTP POST操作和一個(gè)HTTP GET操作。前面是輸入，而后面是輸出。

使用REST的關(guān)鍵是如何抽象資源，抽象的越精確，對(duì)REST的應(yīng)用越好。如何進(jìn)行抽象，面向資源的設(shè)計(jì)和傳統(tǒng)的面向結(jié)構(gòu)和對(duì)象設(shè)計(jì)區(qū)別，資源和對(duì)象，數(shù)據(jù)庫(kù)表之間的差別是另外一個(gè)在分析設(shè)計(jì)時(shí)候要考慮的問(wèn)題。在REST分析設(shè)計(jì)中如何改變傳統(tǒng)的SOAP分析設(shè)計(jì)思想又是一個(gè)重要問(wèn)題。

下文轉(zhuǎn)載自：http://hi.baidu.com/gaohong230/blog/item/cd3924396bc7332fb9998f52.html

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

SOAP

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

REST

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

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

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

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

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

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

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

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

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

這點(diǎn)其實(shí)不僅僅是對(duì)于REST來(lái)說(shuō)的，作為接口設(shè)計(jì)都需要能夠做到這點(diǎn)，也是作為可擴(kuò)展和高效性的最基本的保證，就算是使用SOAP的WebService也是一樣。

SOAP Webservice和RESTful Webservice的比較

成熟度(總的來(lái)說(shuō)SOAP在成熟度上優(yōu)于REST)

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

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

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

效率和易用性(REST更勝一籌)

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

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

安全性：

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

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

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

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

我們的系統(tǒng)要么就是已經(jīng)有了那些需要被發(fā)布出去的服務(wù)，要么就是剛剛設(shè)計(jì)好的服務(wù)，但是開發(fā)人員的傳統(tǒng)設(shè)計(jì)思想讓REST的形式被接受還需要一點(diǎn)時(shí)間。同時(shí)在資源型數(shù)據(jù)服務(wù)接口設(shè)計(jì)上來(lái)說(shuō)按照REST的思想來(lái)設(shè)計(jì)相對(duì)來(lái)說(shuō)要容易一些，而對(duì)于一些復(fù)雜的服務(wù)接口來(lái)說(shuō)，可能強(qiáng)要去按照REST的風(fēng)格來(lái)設(shè)計(jì)會(huì)有些牽強(qiáng)。這一點(diǎn)其實(shí)可以看看各大網(wǎng)站的接口就可以知道，很多網(wǎng)站還要傳入function的名稱作為參數(shù)，這就明顯已經(jīng)違背了REST本身的設(shè)計(jì)思路。而SOAP本身就是面向RPC來(lái)設(shè)計(jì)的，開發(fā)人員十分容易接受，所以不存在什么適應(yīng)的過(guò)程?？偟膩?lái)說(shuō)，其實(shí)還是一個(gè)老觀念，適合的才是最好的

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

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

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

-----------------------------------------------------
Silence, the way to avoid many problems;
Smile, the way to solve many problems;

posted on 2012-02-25 17:21 Chan Chen 閱讀(389) 評(píng)論(0) 編輯收藏所屬分類: Architecture

新用戶注冊(cè) 刷新評(píng)論列表


只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。




網(wǎng)站導(dǎo)航: 博客園 IT新聞 Chat2DB C++博客博問(wèn) 管理
相關(guān)文章: Java MVC 比較計(jì)算500萬(wàn)PV/每天的網(wǎng)站靜態(tài)技術(shù)詳解 DAL Round Robin memcached協(xié)議 RESTful HTTP的實(shí)踐 SOAP Webservice和RESTful Webservice 編譯器工作原理什么是REST

Chan Chen Coding...

導(dǎo)航

統(tǒng)計(jì)

文章分類

文章檔案

最新評(píng)論

SOAP Webservice和RESTful Webservice