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

       在收到新需求Email之前，我對(duì)REST的理解僅僅是通過半懂不懂的看了Fielding的REST博士論文，說實(shí)話當(dāng)時(shí)也就是希望了解這么一個(gè)新概念，對(duì)于其內(nèi)部的思想只是很膚淺的了解了一下。

       ASF的最新需求就是可能需要實(shí)現(xiàn)REST風(fēng)格的WebService集成，因此不得不好好的去看看REST的真正思想含義以及當(dāng)前各大網(wǎng)站的設(shè)計(jì)方式。后面所要表述的也是我這個(gè)初學(xué)者的一些看法和觀點(diǎn)，拋磚引玉，希望在我將REST融入到ASF之前能夠獲得更多的反饋和意見。

SOAP

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

REST

       REST其實(shí)并不是什么協(xié)議也不是什么標(biāo)準(zhǔn)，而是將Http協(xié)議的設(shè)計(jì)初衷作了詮釋，在Http協(xié)議被廣泛利用的今天，越來越多的是將其作為傳輸協(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ù)庫中最基本的增刪改查，而互聯(lián)網(wǎng)上的各種資源就好比數(shù)據(jù)庫中的記錄（可能這么比喻不是很好），對(duì)于各種資源的操作最后總是能抽象成為這四種基本操作，在定義了定位資源的規(guī)則以后，對(duì)于資源的操作通過標(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ì)資源來設(shè)計(jì)的，也就很類似于我們的面向?qū)ο蠛兔嫦蜻^程的設(shè)計(jì)區(qū)別，只不過現(xiàn)在將網(wǎng)絡(luò)上的操作實(shí)體都作為資源來看待，同時(shí)URI的設(shè)計(jì)也是體現(xiàn)了對(duì)于資源的定位設(shè)計(jì)。后面會(huì)提到有一些網(wǎng)站的API設(shè)計(jì)說是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ì)中暴露了這樣的問題，如果要完全按照REST的思想來設(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的老路上，說是REST的理念設(shè)計(jì)，其實(shí)是作了一套私有的SOAP協(xié)議，因此稱之為REST風(fēng)格的自定義SOAP協(xié)議。

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

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

REST vs SOAP

成熟度：

SOAP雖然發(fā)展到現(xiàn)在已經(jīng)脫離了初衷，但是對(duì)于異構(gòu)環(huán)境服務(wù)發(fā)布和調(diào)用，以及廠商的支持都已經(jīng)達(dá)到了較為成熟的情況。不同平臺(tái)，開發(fā)語言之間通過SOAP來交互的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ā)，因此通用性要求不高。

ASF上考慮發(fā)布REST風(fēng)格的Web Service，可以參考幾大網(wǎng)站的設(shè)計(jì)（兄弟公司的方案就是參考了類似于flickr的設(shè)計(jì)模式），但是由于沒有類似于SOAP的權(quán)威性協(xié)議作為規(guī)范，REST實(shí)現(xiàn)的各種協(xié)議僅僅只能算是私有協(xié)議，當(dāng)然需要遵循REST的思想，但是這樣細(xì)節(jié)方面有太多沒有約束的地方。REST日后的發(fā)展所走向規(guī)范也會(huì)直接影響到這部分的設(shè)計(jì)是否能夠有很好的生命力。

總的來說SOAP在成熟度上優(yōu)于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í)，在我看來REST還有一個(gè)很吸引開發(fā)者的就是能夠很好的融合當(dāng)前Web2.0的很多前端技術(shù)來提高開發(fā)效率。例如很多大型網(wǎng)站開放的REST風(fēng)格的API都會(huì)有多種返回形式，除了傳統(tǒng)的xml作為數(shù)據(jù)承載，還有（JSON,RSS,ATOM）等形式，這對(duì)很多網(wǎng)站前端開發(fā)人員來說就能夠很好的mashup各種資源信息。

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

安全性：

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

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

       REST沒有任何規(guī)范對(duì)于安全方面作說明，同時(shí)現(xiàn)在開放REST風(fēng)格API的網(wǎng)站主要分成兩種，一種是自定義了安全信息封裝在消息中（其實(shí)這和SOAP沒有什么區(qū)別），另外一種就是靠硬件SSL來保障,但是這只能夠保證點(diǎn)到點(diǎn)的安全，如果是需要多點(diǎn)傳輸?shù)脑?/span>SSL就無能為力了。安全這塊其實(shí)也是一個(gè)很大的問題，今年在BEA峰會(huì)上看到有演示采用SAML2實(shí)現(xiàn)的網(wǎng)站間SSO，其實(shí)是直接采用了XML-Security和XML-Signature，效率看起來也不是很高。未來REST規(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ì)上來說按照REST的思想來設(shè)計(jì)相對(duì)來說要容易一些，而對(duì)于一些復(fù)雜的服務(wù)接口來說，可能強(qiáng)要去按照REST的風(fēng)格來設(shè)計(jì)會(huì)有些牽強(qiáng)。這一點(diǎn)其實(shí)可以看看各大網(wǎng)站的接口就可以知道，很多網(wǎng)站還要傳入function的名稱作為參數(shù)，這就明顯已經(jīng)違背了REST本身的設(shè)計(jì)思路。

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

總的來說，其實(shí)還是一個(gè)老觀念，適合的才是最好的

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

       REST對(duì)于資源型服務(wù)接口來說很合適，同時(shí)特別適合對(duì)于效率要求很高，但是對(duì)于安全要求不高的場(chǎng)景。而SOAP的成熟性可以給需要提供給多開發(fā)語言的，對(duì)于安全性要求較高的接口設(shè)計(jì)帶來便利。所以我覺得純粹說什么設(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è)看似象摸象樣的皮囊。

REST設(shè)計(jì)的幾種形式

參看了幾個(gè)大型網(wǎng)站的REST風(fēng)格的API設(shè)計(jì)，這里做一下大致的說明：

FaceBook:

請(qǐng)求消息：

       在URI設(shè)計(jì)上采取了類似于REST的風(fēng)格。例如對(duì)于friends的獲取，就定義為friends.get，前面部分作為資源定義，后面是具體的操作，其他的API也是類似，資源+操作，因此就算使用http的get方法都可能作了update的操作，其實(shí)已經(jīng)違背了REST的思想，但是說到，其實(shí)那么復(fù)雜的業(yè)務(wù)接口設(shè)計(jì)下，要通過RUCD來抽象所有的接口基本是不實(shí)際的。在URI定義好以后，還有詳細(xì)的參數(shù)定義，包括類型以及是否必選。

響應(yīng)消息：

       有多種方式，XML,JSON。XML有XSD作為參考。有點(diǎn)類似于沒有Head的SOAP，只不過這里將原來可以定義在WSDL中的XSD抽取出來了。

Flickr:

       請(qǐng)求消息：

       http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value

       這里就可以很明顯看出它所定制的REST請(qǐng)求其實(shí)和RPC沒有什么太大的區(qū)別。

       消息返回：

正確處理返回

<?xml version="1.0" encoding="utf-8" ?>

<rsp stat="ok">

         [xml-payload-here]

</rsp>

錯(cuò)誤處理返回

<?xml version="1.0" encoding="utf-8" ?>

<rsp stat="fail">

         <err code="[error-code]" msg="[error-message]" />

</rsp>

       根據(jù)返回可以看出已經(jīng)違背了REST的思想，還是把Http協(xié)議作為傳輸承載協(xié)議，并沒有真正意義上使用Http協(xié)議作為資源訪問和操作協(xié)議。

       總的來說，只是形式上去模仿REST，自己搞了一套私有協(xié)議。

Ebay：

       請(qǐng)求消息：

       采用xml作為承載，類似于SOAP，不過去除SOAP消息的封裝和包頭，同時(shí)在請(qǐng)求中附加了認(rèn)證和警告級(jí)別等附加信息。

       消息返回：

       類似于SOAP消息，不過刪除了SOAP的封裝和包頭，同時(shí)在返回結(jié)構(gòu)中增加了消息處理結(jié)果以及版本等附加信息。

       這個(gè)很類似于當(dāng)前Axis2框架的做法，將SOAP精簡(jiǎn)，同時(shí)根據(jù)自身需求豐富了安全，事務(wù)等協(xié)議內(nèi)容。

Yahoo Maps：

       請(qǐng)求消息：

       http://local.yahooapis.com/MapsService/V1/geocode?appid=YahooDemo&street=701+First+Ave&city=Sunnyvale&state=CA

       采用REST推薦的方式，URI+Parameters。

       返回消息：

<?xml version="1.0" encoding="UTF-8"?>

<ResultSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns="urn:yahoo:maps"

xsi:schemaLocation="urn:yahoo:maps http://local.yahooapis.com/MapsService/V1/GeocodeResponse.xsd">

 <Result precision="address">

    <Latitude>37.416384</Latitude>

    <Longitude>-122.024853</Longitude>

    <Address>701 FIRST AVE</Address>

    <City>SUNNYVALE</City>

    <State>CA</State>

    <Zip>94089-1019</Zip>

    <Country>US</Country>

 </Result>

</ResultSet>

SOAP的精簡(jiǎn)xml返回，其他信息，例如出錯(cuò)碼等信息由Http協(xié)議頭來承載。

YouTube：

請(qǐng)求消息：

http://www.youtube.com/api2_rest?method=youtube.users.get_profile&dev_id=YOUR_DEV_ID&user=YOUTUBE_USER_NAME

可以看到對(duì)于資源操作的URI定義也是參數(shù)的一部分。

返回消息：

<?xml version="1.0" encoding="utf-8"?>

<ut_response status="ok">

    <user_profile>

        <first_name>YouTube</first_name>

        <last_name>User</last_name>

        <about_me>YouTube rocks!!</about_me>

        <age>30</age>

        <video_upload_count>7</video_upload_count>

    </user_profile>

</ut_response>

       自定義的類SOAP消息。

Amazon：

       請(qǐng)求消息：

       https://Amazon FPS web service end point/?AWSAccessKeyId=Your AWSAccessKeyId

      &Timestamp=[Current timestamp] &Signature=[Signature calculated from hash of Action and Timestamp]

      &SignatureVersion=[Signature calculated from hash of Action and Timestamp]

      &Version=[Version of the WSDL specified in YYYY-MM-DD format] &Action=[Name of the API]

      &parameter1=[Value of the API parameter1] &parameter2=[Value of the API parameter2]

      &...[API parameters and their values]

       返回消息：

       類似于SOAP的自有協(xié)議，消息體中包含了消息狀態(tài)等附加信息。

總結(jié)：

       看了上面那么多網(wǎng)站的設(shè)計(jì)，總結(jié)一下主要有這么幾種設(shè)計(jì)方式。

請(qǐng)求消息設(shè)計(jì)：

1． 基本符合REST標(biāo)準(zhǔn)方式：資源URI定義（資源．操作）+參數(shù)。這類設(shè)計(jì)如果濫用get去處理其他類型的操作，那么和2無異。

2． REST風(fēng)格非REST思想：資源URI定義+參數(shù)（包含操作方法名）。其實(shí)就是RPC的REST跟風(fēng)。

3． 類似于SOAP消息，自定義協(xié)議，以xml作為承載。（可擴(kuò)展，例如鑒權(quán)，訪問控制等），不過那就好比自己定義了一套SOAP和SOAP extends。大型的有實(shí)力的網(wǎng)站有的采取此種做法。

響應(yīng)消息設(shè)計(jì)：

1.       REST標(biāo)準(zhǔn)方式，將Resource State傳輸返回給客戶端，Http消息作為應(yīng)用協(xié)議而非傳輸協(xié)議

2.       以XML作為消息承載體，Http作為消息傳輸協(xié)議，處理狀態(tài)自包含。

3.       自定義消息格式，類似于SOAP，提供可擴(kuò)展部分。

作為遵循REST的理念來看我的選擇是響應(yīng)1和請(qǐng)求1的設(shè)計(jì)。

REST和ASF的集成

ASF要集成REST就現(xiàn)在來看有兩種比較合適的方法。

一．就是采用Axis2的REST實(shí)現(xiàn)，這種方式的好處就是開發(fā)周期短，容易集成，但是請(qǐng)求和響應(yīng)的格式無法改變，資源URI設(shè)計(jì)受限，Axis2的REST其實(shí)就是將SOAP消息精簡(jiǎn)，請(qǐng)求的時(shí)候刪除了SOAP的頭，響應(yīng)的時(shí)候僅僅返回資源信息，如果提供xsd就可以被各種客戶端所解析。并非真正的REST。

二．就是采用Restlet開源框架，將Restlet開源框架集成到ASF中，由于Restlet本身就是可內(nèi)嵌的應(yīng)用框架，因此集成不成問題，同時(shí)Restlet框架只是API結(jié)構(gòu)框架，因此實(shí)現(xiàn)和定義完全分開，集成Restlet以后可以自己實(shí)現(xiàn)其中的解析引擎也可以采用默認(rèn)提供的引擎，同時(shí)對(duì)于內(nèi)嵌Jetty等多種開源項(xiàng)目的支持，將更多優(yōu)勢(shì)融入到了Rest中。看了一下國(guó)內(nèi)也有很多朋友已經(jīng)關(guān)注Restlet開源項(xiàng)目，看了它的架構(gòu)設(shè)計(jì)，個(gè)人覺得還是比較靈活和緊湊的。

題外話

       在寫這篇文章以前寫了一篇調(diào)研報(bào)告群發(fā)給各個(gè)架構(gòu)師們參考，期待反饋。下午正好和我們的首席架構(gòu)師聊了一會(huì)兒。其實(shí)我和他的感覺是一樣的，REST是否真的在我們現(xiàn)有的服務(wù)框架中需要集成，理解了REST的思想再去看應(yīng)用場(chǎng)景，那么可以發(fā)現(xiàn)如果要完全遵循REST的設(shè)計(jì)理念來設(shè)計(jì)接口的話，那么強(qiáng)要去改變現(xiàn)有已經(jīng)存在的或者還未開發(fā)的接口就會(huì)落入為了技術(shù)而技術(shù)，為了潮流而跟風(fēng)的近地。當(dāng)然并不否認(rèn)REST的好，其實(shí)我們兄弟公司的一些業(yè)務(wù)場(chǎng)景有部分的接口十分合適這類設(shè)計(jì)，面向資源，高效，簡(jiǎn)潔，易用都能夠體現(xiàn)出它的價(jià)值。我們將會(huì)和我們的兄弟公司合作，也會(huì)參考他們的設(shè)計(jì)理念，在參考當(dāng)前各個(gè)網(wǎng)站的實(shí)現(xiàn)情況下，部分的采用這類形式的發(fā)布，提供給第三方的ISV，無疑是我現(xiàn)在把REST融入到ASF中最好的理由。

       有了需求去做才不會(huì)陷入為了技術(shù)而技術(shù)，畢竟技術(shù)是由商業(yè)價(jià)值驅(qū)動(dòng)的，同樣社會(huì)上充斥著各種技術(shù)的鼓吹，如果稍不留神就會(huì)陷入跟風(fēng)的潮流中。

歡迎訪問我csdn的blog：http://blog.csdn.net/cenwenchu79/,也歡迎和我做交流,msn:cenwenchu_1979@hotmail.com，關(guān)于SOA,REST,SAAS。