對于國內(nèi)的開發(fā)者來說，在SNS熱潮中第一次接觸了Open API，但這僅僅只是開始。SNS提供的API以及現(xiàn)有的一些分享類網(wǎng)站提供的API，僅僅只是Open API中的一角，所能給開發(fā)者帶來的想象空間，以及所能夠產(chǎn)生的商業(yè)價(jià)值還是十分有限。

今年很多時(shí)間都投入到Open API集成平臺的設(shè)計(jì)和開發(fā)中，因此對于Open API有一些自己的收獲和感想，同時(shí)希望通過對Open API的介紹、實(shí)踐能讓更多的人了解和投入到這種新興開發(fā)模式中。這種開發(fā)模式是一種挑戰(zhàn)，一種創(chuàng)新更是一種機(jī)會(huì)。

一. Open API 的介紹

Open API的發(fā)展

互聯(lián)網(wǎng)應(yīng)用最重要的就是創(chuàng)意和及時(shí)響應(yīng)變更這兩點(diǎn)。傳統(tǒng)軟件拚專業(yè)化和服務(wù)質(zhì)量，但盜版，同質(zhì)競爭，對用戶個(gè)性化需求的服務(wù)支持，使得客戶和軟件生產(chǎn)商都沒有得到滿意結(jié)果。SAAS模式的提出，其實(shí)部分也說明了市場和客戶對于互聯(lián)網(wǎng)應(yīng)用的需求日趨增強(qiáng)，長尾理論更是讓很多草根開發(fā)者看到了未來。但互聯(lián)網(wǎng)應(yīng)用是否僅僅就把傳統(tǒng)軟件搬上網(wǎng)就算是適應(yīng)潮流，改制創(chuàng)新了呢？其實(shí)不然，互聯(lián)網(wǎng)開放帶來的模仿遠(yuǎn)比盜版可怕，軟件的開發(fā)周期長，版本迭代周期長，讓傳統(tǒng)軟件開發(fā)模式下的開發(fā)人員疲于滿足用戶需求。而最重要的創(chuàng)意，傳統(tǒng)軟件專注于專業(yè)化，而專業(yè)化帶來的就是我們過去說SOA需要解決的那些信息豎井，只有將不同行業(yè)的信息串聯(lián)打通，原有的數(shù)據(jù)資源才會(huì)體現(xiàn)出其更大的商業(yè)價(jià)值。 因此Open API出現(xiàn)了，起初也許僅僅是互聯(lián)網(wǎng)企業(yè)內(nèi)部的一種需求，因?yàn)槠髽I(yè)規(guī)模日趨龐大，組織內(nèi)部的協(xié)作也需要模塊化和服務(wù)接口化，隨著業(yè)務(wù)的梳理以及抽象，服務(wù)逐漸不僅僅可以滿足內(nèi)部交互，同時(shí)對外開放給一些商業(yè)合作伙伴，隨之而來的就是數(shù)據(jù)資源價(jià)值的體現(xiàn)讓開放服務(wù)的企業(yè)得到了回報(bào)。當(dāng)越來越多的互聯(lián)網(wǎng)企業(yè)將自己內(nèi)部的業(yè)務(wù)作為服務(wù)提供給外部使用者的時(shí)候，服務(wù)的發(fā)布，流程的規(guī)范化也逐漸形成。REST作為一種輕量級服務(wù)交互規(guī)范也得到了新一代互聯(lián)網(wǎng)企業(yè)的認(rèn)同，加上RSS，JSON，XML已經(jīng)廣泛使用的多種數(shù)據(jù)格式，讓Open API有了公共的基礎(chǔ)，也為Open API的開發(fā)者集成開發(fā)提供了最基本的保障。

當(dāng)前國外的Open API不論是種類，提供商的服務(wù)質(zhì)量，規(guī)范化和使用情況都在這一年里面有了很大的提升，可以說已經(jīng)由初期的發(fā)展轉(zhuǎn)到了較為成熟的發(fā)展。而國內(nèi)，就開放的企業(yè)，提供商的服務(wù)提供成熟度，以及安全等方面的措施，都僅僅只是起步，不過好處在于有可借鑒的模式。不過，明年隨著Open API帶來的商業(yè)價(jià)值逐漸體現(xiàn)，會(huì)讓更多的人加入到互聯(lián)網(wǎng)這種新的應(yīng)用開發(fā)模式中來，同時(shí)也會(huì)給很多開發(fā)者，特別是個(gè)人和小團(tuán)隊(duì)開發(fā)者帶來機(jī)遇。互聯(lián)網(wǎng)行業(yè)就是一個(gè)以小博大的行業(yè)，當(dāng)面對成千上萬的新興資源的時(shí)候，創(chuàng)意加行動(dòng)才是成功的基石。

Open API的形態(tài)

就現(xiàn)在互聯(lián)網(wǎng)上Open API的形態(tài)來看，主要分成兩種：標(biāo)準(zhǔn)REST和類REST(也可以叫做RPC形態(tài))。

RPC形態(tài)其實(shí)就是Web Service的一種延續(xù)，只是少了繁重的解析、安全規(guī)范等。Flickr的Open API大部分就是這種形態(tài)，看看下面的服務(wù)請求URL：

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

服務(wù)請求地址包括了兩部分：1. 服務(wù)的總?cè)肟诘刂穐ttp://api./services/rest/。2.服務(wù)方法以及參數(shù)。這和過去的RPC模式就是一樣的，只是通過Http方式請求，返回的是可以指定格式數(shù)據(jù)內(nèi)容。

REST形態(tài)主要有這么幾點(diǎn)特點(diǎn)：1.服務(wù)地址就是資源定位地址。2.服務(wù)操作就是Http請求中的方法類型（GET,POST,DELETE,PUT），這其實(shí)是抽象現(xiàn)實(shí)當(dāng)中對于服務(wù)的增刪改查操作。Google大部分的REST API就采用了標(biāo)準(zhǔn)的REST風(fēng)格，服務(wù)請求地址URL如下：

http://www.google.com/calendar/feeds/wenchu.cenwc@alibaba-inc.com/allcalendars/full

這個(gè)服務(wù)請求地址是用來定位以我阿里巴巴郵箱注冊的Google賬號的所有日程安排，通過在Http消息頭中配置Get、Post、DELETE、PUT可以對我的日程進(jìn)行操作，而無須登陸到Google上去操作。（后面部分的實(shí)踐中會(huì)有部分介紹如何通過后臺Java代碼直接操作）

對于REST形式的討論在網(wǎng)上一直有，但其實(shí)這種討論沒有什么意義，其實(shí)就好比爭論吃飯是否一定要用筷子，沒有什么技術(shù)是“萬能藥”，也沒有什么技術(shù)好于不好，只有使用它的人是否有足夠的智慧把它應(yīng)用到適合的場景中。

對于類REST的形態(tài)來說優(yōu)點(diǎn)在于對于原有系統(tǒng)的改造較小，“當(dāng)前”用戶使用接受度更高一些，對于邏輯抽象來說更加容易。而REST風(fēng)格的優(yōu)點(diǎn)在于，資源容易管理，系統(tǒng)擴(kuò)展容易，權(quán)限控制可以部分依托于已有的傳輸協(xié)議。兩者的缺點(diǎn)其實(shí)就是對方的優(yōu)點(diǎn)。采取什么模式，其實(shí)還是要根據(jù)企業(yè)本身情況來看，類似于淘寶采用的就是類REST方式，而未來支付寶將會(huì)采用REST的方式，前者要改造整個(gè)系統(tǒng)架構(gòu)和資源數(shù)據(jù)結(jié)構(gòu)基本是不太可能完成的任務(wù)，后者對于業(yè)務(wù)邏輯梳理以及在現(xiàn)有內(nèi)部SOA架構(gòu)體系下抽象出REST風(fēng)格的API并不是一件難事。但最后還是那句話，形態(tài)僅僅只是外在，練功之人修煉好內(nèi)力才是根本，沒有必要為了迎合一種所謂的潮流而去盲目的選擇形態(tài)，因?yàn)榉?wù)提供商將要面對的是高過網(wǎng)站上百甚至更高流量的訪問調(diào)用，如何滿足開發(fā)者業(yè)務(wù)以及非業(yè)務(wù)（穩(wěn)定，高效，安全）的需求，才是最大的挑戰(zhàn)。

Open API的類型

這里指的類型，主要從提供服務(wù)本身內(nèi)容來看。當(dāng)前服務(wù)類型主要可以分成三種：數(shù)據(jù)型，應(yīng)用型，資源型。

現(xiàn)在很多SNS網(wǎng)站的Open API就是屬于數(shù)據(jù)型，也就是將自身的數(shù)據(jù)開放，讓應(yīng)用開發(fā)者根據(jù)已有的數(shù)據(jù)進(jìn)行二次應(yīng)用開發(fā)。

應(yīng)用型其實(shí)應(yīng)該是數(shù)據(jù)型結(jié)合的比較緊密，F(xiàn)lickr的圖片搜索，Google的日程，地圖（地圖數(shù)據(jù)其實(shí)可以自己定義）等等都是屬于應(yīng)用型。應(yīng)用型的數(shù)據(jù)輸入可以是外部的數(shù)據(jù)，也可以是基于已有的數(shù)據(jù)資源進(jìn)行處理。

資源型的代表就是Amazon，Amazon S3就是典型的資源型，當(dāng)然Flickr的圖片存儲(chǔ)服務(wù)等也可以屬于資源型。其實(shí)今年還有一個(gè)被炒得火熱的話題就是云計(jì)算，在云計(jì)算的背后就是需要提供這么一個(gè)資源型的服務(wù)，Amazon EC2如果離開了S3，也就無法存在。其實(shí)這種類型的服務(wù)也是一種未來的趨勢，未來互聯(lián)網(wǎng)應(yīng)用如果要培植草根級開發(fā)者，就需要有這樣的溫室，Google 的App engine如果在多一些語言環(huán)境版本，那么會(huì)讓更多的開發(fā)者有夢想實(shí)現(xiàn)的空間。

在回過頭來看三種類型的服務(wù)，其實(shí)有著很強(qiáng)的層次關(guān)系，就如下圖：

圖1 Open API的類型

Open API交互的數(shù)據(jù)格式

對于互聯(lián)網(wǎng)應(yīng)用來說，最大的特點(diǎn)也是最大的優(yōu)點(diǎn)就是基于Http協(xié)議開發(fā)成為應(yīng)用開發(fā)的統(tǒng)一標(biāo)準(zhǔn)。對于使用的語言，采用的操作系統(tǒng)和應(yīng)用部署平臺都沒有太多的限制。Web Service采用xml作為數(shù)據(jù)傳輸承載，制定了解析標(biāo)準(zhǔn)（以及后來安全，轉(zhuǎn)發(fā)等標(biāo)準(zhǔn)）為開發(fā)者異構(gòu)系統(tǒng)的信息交互帶來了可能，也成為至今為止應(yīng)用最廣泛的服務(wù)集成方式。而隨著Web2.0發(fā)展，RSS、Atom、JSON的大規(guī)模應(yīng)用，對于數(shù)據(jù)交互格式有了更多的選擇。

服務(wù)請求就是標(biāo)準(zhǔn)的Http的請求，對于文件類上傳的服務(wù)采用HTTP Multipart的格式。編碼方式基本都采用UTF-8的編碼方式。

在Open API的數(shù)據(jù)返回格式方面，大部分的網(wǎng)站優(yōu)先提供Xml、JSON的數(shù)據(jù)返回，Google定義的GData就是在Atom基礎(chǔ)上作了擴(kuò)展，還有一些網(wǎng)站提供了php的數(shù)據(jù)返回。同時(shí)有些網(wǎng)站會(huì)在Open API的基礎(chǔ)上作更高的一層封裝，類似于Google Map，可以通過java script框架來直接使用。

當(dāng)前國外的Open API使用狀況

我這里只列了前四名的一個(gè)比例對照,但是前面四名占有總的Mash-up 的比例已經(jīng)高達(dá)80%左右。

從這個(gè)占有率可以看出，API首先吸引開發(fā)者的應(yīng)該是API應(yīng)用場景是否廣泛，Google Map其實(shí)就是最好的說明，地圖類服務(wù)可以和各種行業(yè)結(jié)合起來為人們生活服務(wù)。其次就是API的專業(yè)化，后面三位這方面都是本類服務(wù)中作的最出色或者說是暫時(shí)還沒有人可以作到的。Flickr的服務(wù)就是圍繞著圖片，但是Flickr對于圖片Tag專業(yè)性的設(shè)計(jì)讓使用者的需求得到了最大的滿足，同時(shí)也為開發(fā)者提供了很多隱性的資源。YouTube借助著Google在搜索領(lǐng)域的強(qiáng)大優(yōu)勢以及自身的行業(yè)能力也吸引了廣大的開發(fā)者。而Amazon多層次的API結(jié)構(gòu)化設(shè)計(jì)，為開發(fā)者提供了整套的開發(fā)解決方案（EC2,S3,SQS,SimpleDB作為基礎(chǔ)的Framework; FPS,DevPay作為配套支付服務(wù)支持，Alexa Web Search作為搜索），同時(shí)加上自身的強(qiáng)大的電子商務(wù)基礎(chǔ)，也成為了很多開發(fā)者的首選。

其實(shí)從國外的Open API來看，如果要成為開發(fā)者的服務(wù)提供商首選，那么就需要在服務(wù)特色，服務(wù)質(zhì)量，服務(wù)配套化（社區(qū)，SDK，開發(fā)框架，整體解決方案）上作文章。很多企業(yè)已經(jīng)有了吸引人的數(shù)據(jù)資源（類似于淘寶，YouTube，F(xiàn)lickr），或者擁有行業(yè)內(nèi)強(qiáng)大的專業(yè)能力（類似于Google的搜索，地圖，支付寶的支付）都可以比較容易的占有市場優(yōu)勢，而類似于國內(nèi)現(xiàn)在很多SNS網(wǎng)站商業(yè)模式已經(jīng)被復(fù)制的差不多了，數(shù)據(jù)內(nèi)容其實(shí)也部分上下，因此如何能夠做好服務(wù)特色，質(zhì)量，配套化才是未來在Open API領(lǐng)域走的更遠(yuǎn)的基石。

二． Open API的實(shí)踐

Open API實(shí)踐部分根據(jù)授權(quán)策略的不同和使用方式的不同分成幾階段內(nèi)容，完整的代碼可以去Google Code下載（http://rest-demo./files/demostore.rar ）。

注：代碼中的部分用戶名和密碼以及應(yīng)用id都需要采用自己申請的內(nèi)容作替換，代碼都是Java的后臺程序代碼，主要考慮實(shí)踐即可，同時(shí)這部分代碼僅僅是作為測試，結(jié)構(gòu)和錯(cuò)誤處理都是沒有作太多的關(guān)注。

三． 類授權(quán)策略

免授權(quán)只需要開發(fā)者申請應(yīng)用ID即可使用服務(wù)。應(yīng)用授權(quán)是最基礎(chǔ)的Open API開發(fā)授權(quán)策略，作用是讓服務(wù)提供商能夠核對每一次服務(wù)請求者的身份，同時(shí)也保證了服務(wù)開發(fā)商的自身利益，與免授權(quán)之間的區(qū)別就是是否需要在請求中帶上數(shù)字簽名來交驗(yàn)請求者身份。用戶授權(quán)一般是基于應(yīng)用授權(quán)之上的更高層次的授權(quán)認(rèn)證，為了保障使用應(yīng)用的終端用戶數(shù)據(jù)不會(huì)在用戶不知情或未授權(quán)的情況下被訪問和修改，使用戶隱私泄露或者蒙受損失。

免授權(quán)和應(yīng)用授權(quán)類服務(wù)的開發(fā)

Yahoo的Search引擎以及Boss服務(wù)（Build your Search Service）都是屬于免授權(quán)類服務(wù)。

首先，上Yahoo開發(fā)者網(wǎng)站申請應(yīng)用身份( http://developer.yahoo.com/），這里首先需要擁有一個(gè)Yahoo的Id，然后即可申請應(yīng)用Id，一個(gè)開發(fā)者可以申請多個(gè)應(yīng)用Id。

客戶端測試代碼片段如下：

接下來就看看運(yùn)行效果吧：

testYahooSearch()的運(yùn)行結(jié)果如下：

測試運(yùn)行結(jié)果是搜索結(jié)果集的xml描述，可以根據(jù)ImageSearchResponse.xsd來解析返回的內(nèi)容。

testBossSearch()運(yùn)行的結(jié)果如下：

測試運(yùn)行的結(jié)果是已經(jīng)經(jīng)過XPath初步處理的結(jié)果，提供了下一頁的入口URL地址，以及本次搜索出來的結(jié)果集。

通過阿里軟件服務(wù)集成平臺訪問淘寶非用戶隱私信息類API就屬于應(yīng)用授權(quán)類服務(wù)。與上面范例差異在于調(diào)用發(fā)送方法時(shí)傳入了secretcode，進(jìn)行參數(shù)簽名（參數(shù)中增加了時(shí)間戳）。

由上面的例子可以看出，對于公開信息的訪問，Open API接入簡單，使用方便。

用戶授權(quán)類服務(wù)的開發(fā)

用戶授權(quán)類服務(wù)，首先就要解決如何讓用戶能夠在知情的情況下授權(quán)給應(yīng)用開發(fā)商獲取和操作用戶個(gè)人的數(shù)據(jù)，實(shí)現(xiàn)用戶需求。在傳統(tǒng)意義上通常會(huì)讓用戶輸入某一個(gè)網(wǎng)站的用戶名和密碼，就類似于現(xiàn)在的很多SNS讓用戶輸入msn,qq賬號來獲取用戶好友信息，但是其實(shí)這樣對于用戶來說風(fēng)險(xiǎn)很大，特別是一些個(gè)人隱私性很強(qiáng)的信息或者是涉及到金錢的操作。因此現(xiàn)在大部分的服務(wù)提供商采取的是OAuth方式的認(rèn)證或者是類似于OAuth，OAuth的具體細(xì)節(jié)我就不在這里贅述了，網(wǎng)上有很詳細(xì)地資料，這里就大致把流程原理畫一下。

圖2 OAuth流程

這里將采用Flickr圖片上傳作為測試范例：

首先，還是要擁有Flickr的賬號，然后同時(shí)去申請應(yīng)用id。

具體的代碼片斷如下：

看看執(zhí)行效果：

首先控制臺會(huì)輸出：if done then input 'ok' to console!，同時(shí)彈出IE窗口如下：

輸入用戶名和密碼以后會(huì)看到如下界面，就表示授權(quán)成功了。

在控制臺中輸入ok，然后回車?？吹饺缦绿崾荆?/p>

然后就輸入你需要上傳的圖片的地址，例如我輸入我的blog的頭像地址：http://avatar.profile.csdn.net/3/5/1/1_cenwenchu79.jpg。然后回車，會(huì)看到新彈出一個(gè)頁面，里面就是上傳到你Flickr中的圖片。

以上就是一次用戶授權(quán)API的完整操作，對比應(yīng)用授權(quán)，個(gè)人授權(quán)相對來說會(huì)比較復(fù)雜一些，同時(shí)根據(jù)調(diào)用應(yīng)用的不同，也會(huì)有不同的授權(quán)流程（Web應(yīng)用，桌面應(yīng)用，手機(jī)應(yīng)用）。但就現(xiàn)在國內(nèi)外的Open API使用來看，大致的思想都比較相似，也就是OAuth的思想，但是細(xì)節(jié)部分會(huì)有不少差異，例如Token時(shí)效，維護(hù)方，操作范圍等。

Mash-up 的范例

Mash-up在基維百科中定義是這樣的（In web development, a mash-up is a web application that combines data from more than one source into a single integrated tool）。數(shù)據(jù)的一種集成。其實(shí)Open API真正的目的就是希望夠讓信息在交互中產(chǎn)生更大的價(jià)值。

這個(gè)范例的場景是淘寶賣家上傳上品信息的同時(shí)需要有商品的圖片，通常商家就不得不自己再去找一些符合自己商品的縮略圖，這里我采用上面使用過的Yahoo BOSS搜索縮略圖，將符合條件的縮略圖選擇一個(gè)作為商品的描述圖片再上傳到淘寶。這樣就將整個(gè)淘寶賣家編輯上傳寶貝的流程簡化了，并且對于商品圖片描述來說會(huì)有更多更好的選擇。

淘寶的Open API都通過阿里軟件的服務(wù)集成平臺發(fā)布（后面章節(jié)會(huì)對服務(wù)集成平臺有介紹和描述），具體的使用流程其實(shí)和前面描述的兩種服務(wù)獲取方式一樣，只是在用戶授權(quán)方面對于應(yīng)用開發(fā)者來說更加簡便。

第一步，還是申請應(yīng)用賬號和安全密碼，不過需要首先擁有一個(gè)阿里巴巴中文站或者淘寶、阿里軟件的賬號，然后登錄http://isv./isv/portal/home/home.jspa，然后選擇開發(fā)者聯(lián)盟的標(biāo)簽，里面有說明文檔和指南。

第二步，你需要有一個(gè)淘寶賬號，并且開了網(wǎng)店。

第三步，客戶端代碼，代碼片斷如下：

運(yùn)行結(jié)果：

首先控制臺會(huì)輸出：if done then input 'ok' to console! 然后會(huì)有IE彈出界面如下：

輸入用戶信息以后將會(huì)進(jìn)入如下頁面：

點(diǎn)擊確認(rèn)，然后關(guān)閉網(wǎng)頁。在控制臺中輸入ok，并且回車。此時(shí)就會(huì)發(fā)現(xiàn)，淘寶賣家中的一個(gè)寶貝被修改了價(jià)格和圖片，不過由于淘寶店的更新會(huì)有滯后，因此需要去我的淘寶里面看正在出售中的寶貝。

可以看到，冰激凌圖片已經(jīng)上傳到了地毯上去了，這里當(dāng)然只是試驗(yàn)看效果而已。

三. 服務(wù)集成平臺

經(jīng)過前面的介紹和實(shí)踐兩部分，在Open API在概念和實(shí)際操作上都有了一定的理解和認(rèn)識，這里就再談?wù)劮?wù)集成平臺的作用、角色和定位。這里大致描述一下集成平臺當(dāng)前的實(shí)現(xiàn)點(diǎn)，這些實(shí)現(xiàn)點(diǎn)也就是服務(wù)集成平臺的價(jià)值所在。

服務(wù)集成平臺（SIP）的角色和作用

圖 3 SIP Role

ISV（獨(dú)立軟件開發(fā)商）最關(guān)心什么？

1. 服務(wù)資源是否豐富。這關(guān)系著是否能夠創(chuàng)新。
2. 服務(wù)質(zhì)量是否有保證。這關(guān)系著是否能夠滿足用戶最基本的需求。
3. 開發(fā)集成是否便利。這關(guān)系著開發(fā)成本。

ISP（獨(dú)立服務(wù)提供商）最關(guān)心什么？

1. 服務(wù)安全性是否可靠。如果損害到自身或者用戶利益，則就失去了原來開放的初衷。
2. 是否有足夠多的應(yīng)用開發(fā)者使用服務(wù)。
3. 服務(wù)的非業(yè)務(wù)性需求是否可以滿足。（服務(wù)監(jiān)控告警，計(jì)費(fèi)，統(tǒng)計(jì)分析等）

SIP是連接ISV和ISP的“橋梁”。它能解決什么雙方最關(guān)心的什么問題？

1. 豐富的ISV資源以及豐富的ISP資源。這其實(shí)是一個(gè)良性循環(huán)的過程，就好比一個(gè)建材市場，買家和賣家數(shù)量遠(yuǎn)遠(yuǎn)要比在單獨(dú)一家實(shí)體店中多，從淘寶的B2C模式就可以看出，市場大了以后傳統(tǒng)的“大鱷”都要聚集人氣。
2. 統(tǒng)一安全標(biāo)準(zhǔn)和多種控制策略，即保證了ISP的安全，又能夠讓ISV開發(fā)起來方便。在前面實(shí)踐過程中可以很明顯的看到，眾多的應(yīng)用id，各自的安全流程，讓開發(fā)者M(jìn)ash up無形中增加了很大的開發(fā)成本和維護(hù)成本。
3. SIP目的就是讓ISP專注于業(yè)務(wù)服務(wù)的開發(fā)，而將非業(yè)務(wù)性的需求，如安全，服務(wù)監(jiān)控預(yù)警，日志分析統(tǒng)計(jì)，計(jì)費(fèi)，社區(qū)等都一攬子解決。這樣既解決了ISP的第三個(gè)問題，同時(shí)也為ISV關(guān)心的服務(wù)質(zhì)量無形中作了促進(jìn)。

在年初的時(shí)候，分析和研究國外的Open API時(shí)，感覺類似于SIP形態(tài)的產(chǎn)品在國外還沒有，大家都是各做各的，但這陣子回過頭來看，YouTube和Google開放平臺，F(xiàn)lickr和Yahoo開放平臺，這些平臺都屬于SIP形態(tài)的產(chǎn)品，而且Google要比當(dāng)前我們做的SIP還要更進(jìn)一步，那就是數(shù)據(jù)格式規(guī)范化(GData)，而SIP當(dāng)前僅僅只是做到流程規(guī)范化。

那是否任何公司都適合去做SIP這類形態(tài)的平臺呢，這不僅僅是技術(shù)問題，還是一個(gè)資源的問題。阿里巴巴每一家子公司都有實(shí)力去做一個(gè)這樣的開放平臺，但各自獨(dú)做一套的結(jié)果就是資源浪費(fèi)，同時(shí)技術(shù)沒有得到積累（SIP技術(shù)積累是在ISV和不同形態(tài)的ISP接入中逐漸產(chǎn)生的），最重要的是這些子公司其實(shí)真正需要關(guān)注的是如何將業(yè)務(wù)和數(shù)據(jù)開放給開發(fā)者，吸引更多的開發(fā)者來構(gòu)建出圍繞Open API的創(chuàng)新應(yīng)用，最大化數(shù)據(jù)和服務(wù)的商業(yè)價(jià)值。

服務(wù)集成平臺功能特性

服務(wù)路由

服務(wù)集成平臺就好比硬件里面的“路由器”，服務(wù)調(diào)用者只需要提供服務(wù)注冊的名稱，就可以調(diào)用到某一個(gè)服務(wù)提供商提供的服務(wù)，對于調(diào)用者來說無需關(guān)心此服務(wù)的地址以及提供者。

根據(jù)現(xiàn)階段的服務(wù)集成來看，主要分成四類的服務(wù)路由，同步服務(wù)路由，異步服務(wù)路由，訂閱服務(wù)路由，大數(shù)據(jù)量上傳服務(wù)。同步服務(wù)路由就是普通的Http無狀態(tài)單次請求和響應(yīng)。異步服務(wù)路由應(yīng)用于服務(wù)提供商提供的服務(wù)無法在當(dāng)時(shí)處理完畢，先返回一個(gè)請求響應(yīng)，當(dāng)服務(wù)處理結(jié)束以后再將服務(wù)處理結(jié)果返回給服務(wù)調(diào)用者（短信業(yè)務(wù)就是一種異步服務(wù)）。訂閱服務(wù)和互聯(lián)網(wǎng)上RSS之類的訂閱十分相似，服務(wù)調(diào)用者只需要訂閱服務(wù)即可獲得服務(wù)提供商推送的服務(wù)內(nèi)容。大數(shù)據(jù)量上傳服務(wù)其實(shí)也是屬于同步服務(wù)，但是由于消耗資源和性能壓力不同，因此被單獨(dú)作優(yōu)化處理。

對于服務(wù)形態(tài)不同，服務(wù)路由需要支持REST風(fēng)格的服務(wù)路由和類REST風(fēng)格服務(wù)的路由，但對于開發(fā)者來說，調(diào)用的方式都是用服務(wù)名稱來路由。

正式環(huán)境和測試環(huán)境的隔離和切換

對于服務(wù)開發(fā)者來說，在應(yīng)用開發(fā)期間需要有外部測試環(huán)境的支持，在商用以后需要有正式環(huán)境支持，同時(shí)兩個(gè)環(huán)境的切換需要盡量的簡單。

服務(wù)集成平臺支持服務(wù)提供商提供測試環(huán)境和正式環(huán)境的不同服務(wù)路由，同時(shí)兩套環(huán)境切換成本低。當(dāng)服務(wù)提供商只有一套環(huán)境的時(shí)候可以根據(jù)策略配置的不同，對調(diào)用者訪問的范圍，頻度，次數(shù)作限制，保證測試服務(wù)不影響正式服務(wù)。

安全

提供對應(yīng)用身份認(rèn)證以及服務(wù)提供商身份認(rèn)證的支持，采用多種數(shù)字簽名算法實(shí)現(xiàn)基本的身份認(rèn)證，支持IP白名單和動(dòng)態(tài)算法更新后端插件提供更高級別的服務(wù)安全保證。

細(xì)化了用戶授權(quán)流程。對于用戶Token細(xì)分為請求級別和會(huì)話級別，同時(shí)對于會(huì)話級別的權(quán)限操作，失效時(shí)間可根據(jù)服務(wù)提供商的配置自定義。同時(shí)平臺托管維護(hù)每個(gè)應(yīng)用每個(gè)用戶的多身份綁定Token，降低服務(wù)提供商開發(fā)維護(hù)成本。

服務(wù)提供商可配置服務(wù)訪問量控制和頻率控制（所有應(yīng)用或者單個(gè)應(yīng)用）。也支持配置需要訂購才可以使用的服務(wù)（有限次數(shù)訂購，無限次數(shù)訂購）。

支持多級服務(wù)安全策略配置，為服務(wù)配置（無授權(quán)，應(yīng)用授權(quán)，用戶授權(quán)，可選用戶授權(quán)）等多種級別的安全策略。注：可選用戶授權(quán)是指如果沒有被用戶授權(quán)的情況下使用接口將返回部分公開數(shù)據(jù)，而在用戶授權(quán)情況下使用則返回全部的私有和公開數(shù)據(jù)。

對服務(wù)提供商多級分類，提供不同的安全策略組合。

監(jiān)控與告警

服務(wù)使用者服務(wù)使用出錯(cuò)監(jiān)控和告警。

服務(wù)提供商提供的服務(wù)可用性，超時(shí)狀況的監(jiān)控和告警。

服務(wù)集成平臺服務(wù)處理狀況，內(nèi)部模塊運(yùn)行狀況監(jiān)控和告警。

日志采集與統(tǒng)計(jì)分析

高并發(fā)下日志采集異步處理，采集服務(wù)正常訪問和異常訪問日志，采集用戶綁定類，異步服務(wù)類，平臺內(nèi)部服務(wù)類等特殊日志。

每日，每周，每月訪問日志統(tǒng)計(jì)分析，基礎(chǔ)報(bào)表和趨勢分析圖的創(chuàng)建。

支持分析結(jié)果預(yù)警配置。

歷史統(tǒng)計(jì)數(shù)據(jù)管理和歸檔。

平臺內(nèi)置服務(wù)

平臺為服務(wù)提供商以及服務(wù)調(diào)用者提供了平臺級別的服務(wù)，為開發(fā)商和服務(wù)提供者獲取平臺業(yè)務(wù)數(shù)據(jù)以及運(yùn)行期配置安全策略提供方便。

平臺提供一系列平臺模塊監(jiān)控、配置、重置服務(wù)，支持在線問題查找、定位、解決的一套機(jī)制。

非功能性需求（當(dāng)前情況）

性能：壓力測試單機(jī)500并發(fā)用戶1600+的tps，多機(jī)處理能力線性增長。

模塊化：內(nèi)部處理模塊化結(jié)構(gòu)，支持運(yùn)行期配置、裝載、卸載。

容錯(cuò)：服務(wù)集成平臺核心數(shù)據(jù)都緩存在Memcache中，因此Memcache集群以及容錯(cuò)策略的擴(kuò)展都為平臺穩(wěn)定和容錯(cuò)作了基礎(chǔ)保證。

配套支持

通過ISV,ISP,Admin三個(gè)Portal，使開發(fā)者，服務(wù)提供商以及后臺維護(hù)人員能夠自主維護(hù)基本信息和查看相關(guān)數(shù)據(jù)。

為開發(fā)者提供社區(qū)，測試區(qū)的支持，并且提供開發(fā)工具包和文檔，方便開發(fā)。

擴(kuò)展集成

支持不同平臺的服務(wù)集成。支持Google,Flickr,Yahoo等等不同的服務(wù)平臺的服務(wù)集成，當(dāng)前還沒有完全將安全體系集成，只能夠支持安全流程透傳，消息數(shù)據(jù)完整過濾。

服務(wù)集成平臺的一些發(fā)展趨勢

1. 數(shù)據(jù)集成和流程集成
   當(dāng)前很多服務(wù)都是基礎(chǔ)的數(shù)據(jù)型服務(wù)，使用者通過數(shù)據(jù)篩選獲取相應(yīng)的數(shù)據(jù)，然后展現(xiàn)給用戶，這些服務(wù)的集成相對來說功能比較單一，流程也不復(fù)雜。但隨著服務(wù)提供商的發(fā)展，數(shù)據(jù)類型服務(wù)將會(huì)作為基礎(chǔ)服務(wù)的一部分，而越來越多業(yè)務(wù)處理型服務(wù)會(huì)成為使用者的首選，此時(shí)，如何讓服務(wù)和服務(wù)之間數(shù)據(jù)互通，服務(wù)可以通過一定的描述編排，就會(huì)變得越來越有價(jià)值，就如前面提到的，Google采用GData作為數(shù)據(jù)規(guī)范格式，同時(shí)對于安全流程的統(tǒng)一制定，為第二階段的集成打下了基礎(chǔ)。
2. 服務(wù)基礎(chǔ)平臺間的互通
   最近Open ID也再次由于各大網(wǎng)站的支持而被人們廣泛關(guān)注，在未來Open API體系中，伴隨著Open ID的發(fā)展，服務(wù)基礎(chǔ)平臺之間的服務(wù)互通也將會(huì)變得越來越容易，但是數(shù)據(jù)的安全性也會(huì)對每個(gè)服務(wù)平臺要求更高。
3. 服務(wù)集成平臺的層次化
   在這篇文章的介紹中僅僅介紹的是最基礎(chǔ)的Open API的Mash up，其實(shí)當(dāng)前已經(jīng)有更高層次的Mash up被廣為使用，JavaScript、ActionScript、Flash/Flex這些技術(shù)使得展現(xiàn)更為靈活和豐富。因此未來的服務(wù)集成平臺將會(huì)層次化，從數(shù)據(jù)集成到流程集成到UI集成，會(huì)成為一套自下而上的解決方案，適合各種場景的裁剪選擇。

四. 對Open API的一些思索和感觸

不同角色，不同收獲

平臺開發(fā)者：

這是我的本職工作和角色。當(dāng)淘寶等服務(wù)提供商的服務(wù)接上來以后我就要為它的安全和穩(wěn)定負(fù)責(zé)。當(dāng)SIP一旦出現(xiàn)問題，那么服務(wù)提供商和軟件開發(fā)商將都無法再正常工作，套用蜘蛛俠的一句話：“能力越大，責(zé)任越大”。作平臺的尤為如此。

服務(wù)提供商：

服務(wù)提供商接觸的最多的就是淘寶的同學(xué)，首先看到的就是做一個(gè)服務(wù)提供商很不容易，要把原有系統(tǒng)中復(fù)雜的邏輯抽象出來并不是抽象一個(gè)公用函數(shù)那么簡單，同時(shí)對于模塊化，邊界性，容錯(cuò)性方面的要求要遠(yuǎn)遠(yuǎn)高于封閉系統(tǒng)開發(fā)本身，因?yàn)槟悻F(xiàn)在要面對的是倍于原有訪問量上百甚至上千的調(diào)用者，對任何一個(gè)小疏漏都可能帶來災(zāi)難性的影響。

軟件開發(fā)商：

在寫這個(gè)文檔以前，最多也就是寫幾個(gè)測試的Demo來測試SIP環(huán)境中的服務(wù)，在淘寶API討論群中會(huì)看到很多新的或者老的ISV在抱怨或者詢問一些自己覺得很簡單的問題（例如簽名等等），同時(shí)在監(jiān)控中也看到很多及其簡單錯(cuò)誤統(tǒng)計(jì)數(shù)都會(huì)有很高的比例。但是經(jīng)歷過這次對于各種各樣國內(nèi)國外的API的開發(fā)，讓我深刻體會(huì)到了開發(fā)者的一些痛苦（當(dāng)然我沒有去使用各個(gè)開發(fā)社區(qū)的第三方語言開發(fā)包，這也增加部分的開發(fā)難度），我也曾因?yàn)楹灻麊栴}在豆瓣API測試的時(shí)候折騰了半天，在調(diào)試Google Calendar的時(shí)候不得不跟蹤開發(fā)包代碼才找到了一些隱晦的設(shè)置通過測試。其實(shí)Open API在國內(nèi)國外都沒有完全可以稱得上成熟，因此開發(fā)者其實(shí)是最容易受到影響的。同時(shí)他們面對著最難應(yīng)付的客戶，平臺或者服務(wù)提供商出現(xiàn)問題，客戶最先抱怨的也是服務(wù)開發(fā)商，因此作為平臺開發(fā)者和ISP其實(shí)都要給與一定的支持和幫助，這樣才會(huì)走向更好的良性循環(huán)。

其實(shí)上面說的那些無非都是大家最長說的換位思考，一個(gè)新興的開發(fā)模式需要各方合作才會(huì)走向良好的發(fā)展方向。

創(chuàng)意就是財(cái)富

記得前一陣子支付寶能夠在上海交水電費(fèi)引起了很多人關(guān)注，杭州本地論壇中都有很多人在問：“什么時(shí)候杭州能夠也用支付寶交水電費(fèi)就好了”。其實(shí)如果開放了支付服務(wù)和水電繳費(fèi)服務(wù)，這種Mash up的應(yīng)用又有什么難的呢？你都可以直接每個(gè)自然月通過Google Calendar設(shè)置好日程安排，自動(dòng)繳完所有的費(fèi)用，然后短信提示一下即可。未來當(dāng)各行各業(yè)發(fā)現(xiàn)了自身資源的潛在價(jià)值以后，以服務(wù)的方式通過平臺互通，那么創(chuàng)意就是財(cái)富。

作者介紹：岑文初，就職于阿里軟件公司研發(fā)中心平臺一部，任架構(gòu)師。當(dāng)前主要工作涉及阿里軟件開發(fā)平臺服務(wù)框架（ASF）設(shè)計(jì)與實(shí)現(xiàn)，服務(wù)集成平臺（SIP）設(shè)計(jì)與實(shí)現(xiàn)。沒有什么擅長或者精通，工作到現(xiàn)在唯一提升的就是學(xué)習(xí)能力和速度。個(gè)人Blog為：http://blog.csdn.net/cenwenchu79。