時下互聯網上最流行的莫過于“社交網絡”。在國外,燒了投資人無數銀子的SNS公司終于一個接一個地上市;在國內新浪、騰訊、搜狐、甚至百度都紛紛調整戰略將微博作為他們一個重要的戰略布局。
對于這些巨頭,微博要么是鞏固自己帝國版圖的戰略性防御武器,要么是追趕對手甚至反戈一擊的絕好機會。
對于媒體人或者那些意見領袖們,微博是他們的擴音器,同時他們更希望微博日后成為推動社會進步的加速器。
對于大量的草根用戶,在他們厭倦了傳統媒體上對權威的“90度仰視”和網絡中對同伴的“0度交流”之后,微博提供給他們了一個獨特的45度視角,使他們在聆聽的同時還可以有效的表達。
所以,幾乎是一夜之間微博紅遍中國大江南北。在這樣一個市場面前,創業者沒有理由不激動。問題是,微博(SNS平臺)對于創業者到底意味著什么? Linkedin創始人Reid Hoffman最近的一個觀點可能代表了美國資本市場的普遍看法:“if Web 1.0 involved“go search, get data”and some limited interactivity;and if Web 2.0involves “real identities”and“real relationships”,then Web 3.0 willbe “real identities generating massive amounts of data.”。這就好像在說現在是最好的時代也是最壞的時代。
面對如此大量的用戶產生的內容,創業者第一次有機會在創業的第一天就擁有一個上億用戶的平臺,以及這個平臺上屬于每個用戶的獨特數據。但與此同時,如果不對這些內容加以分析利用,互聯網的效率就會被“信息過載”嚴重降低。這是一個剛性需求。但創業者擔心的卻是這些社會化平臺本身–他們是否開放?他們現在有多么開放?他們未來會多開放?我們可以從很多維度討論這個問題:企業戰略,社會趨勢,技術發展等等。
但創業者最關心的卻是這些平臺提供的API(應用程序接口)。畢竟,內容屬于平臺,而API是其他人獲取這些內容幾乎唯一的合法途徑。API種類是否豐富,數據是否完整,使用時限制又有多少,直接影響了創業點子的可行性。因此,我們就從以上幾個方面對目前國內最流行的兩個微博平臺,騰訊和新浪,做一個簡單的比較。
API多樣性
開發者使用一個開放平臺最關心的是“這個平臺提供了哪些API”以及“這些API又能實現什么功能”。新浪目前開放了近100個API接口,和騰訊相比,開放的方式更接近twitter。如果我們仔細的對比一下新浪和twitter的API,我們就會發現,雙方不僅在數量上相當,在功能上新浪幾乎提供了所有twitter開放的服務。相比之下,騰訊API的種類就少很多,目前只有60個左右。進一步來看,我們可以將微博平臺提供的服務大致分為:公共內容,用戶內容,用戶關系鏈以及其他輔助功能(例如搜索)。
在公共內容上面,騰訊和新浪都提供了獲取公共微博和熱門話題的接口。但新浪的熱門話題接口更加豐富,包括了每周,每日和每小時的熱門話題。而騰訊只提供了一個“話題熱榜”接口,返回當前最流行的話題。
在“用戶內容”上,兩個平臺的差別更加明顯。新浪API接口以用戶為中心,騰訊則更偏重提供基礎數據。例如,對于微博的轉發和評論,新浪直接提供了API可以獲取一個用戶發出和收到的評論。而騰訊只提供了由”獲取一條微博所有評論“的API。這意味著,在新浪微博上通過一個API請求就可以獲得的”某個用戶收到的評論“,在騰訊平臺上,開發者需要先獲得用戶發表的微博列表,然后再拿著每條微博向騰訊再次請求其所有評論。不僅如此,目前為之騰訊仍未開放“獲取一個用戶所發表的評論”的接口。
對于”用戶關系鏈“的開放,騰訊和新浪差別不大,第三方都可以拿到一個用戶的粉絲和好友列表。由于騰訊微博本身提供了”特別收聽“功能,通過其API還可以獲得一個用戶”特別收聽列表“。
最后,在”輔助功能“上面,雙方都提供了”好友推薦“和比較完整的搜索服務(搜索用戶,搜索微博),但新浪目前還支持獲得一個用戶”可能感興趣的標簽“,這個API為做基于微博的推薦服務提供了有效的參考信息。
API的數量和種類是多樣性的一個方面,其另外一個方面則是每個API的功能性。與騰訊相比,新浪的API功能更加豐富。以”獲取用戶的微博“這個接口為例,新浪接受的參數如下:
請求參數
必選 | 類型及范圍 | 說明 | |
source | true | string | 申請應用時分配的AppKey,調用接口時候代表應用的唯一身份。(采用OAuth授權方式不需要此參數) |
:id | false | int64/string | 根據用戶ID(int64)或者微博昵稱(string)返回指定用戶的最新微博消息列表。該參數為REST風格參數,參見注意事項 |
user_id | false | int64 | 用戶ID,主要是用來區分用戶ID跟微博昵稱。當微博昵稱為數字導致和用戶ID產生歧義,特別是當微博昵稱和用戶ID一樣的時候,建議使用該參數 |
screen_name | false | string | 微博昵稱,主要是用來區分用戶UID跟微博昵稱,當二者一樣而產生歧義的時候,建議使用該參數 |
since_id | false | int64 | 若指定此參數,則只返回ID比since_id大(即比since_id發表時間晚的)的微博消息。 |
max_id | false | int64 | 若指定此參數,則返回ID小于或等于max_id的微博消息 |
count | false | int,默認值20,最大值200。 | 指定每頁返回的記錄條數。 |
page | false | int,默認值1。 | 頁碼。注意:最多返回200條分頁內容。 |
如果:id、user_id、screen_name三個參數均未指定,則返回當前登錄用戶最近發表的微博消息列表。 | |||
base_app | false | int | 是否基于當前應用來獲取數據。1為限制本應用微博,0為不做限制。 |
feature | false | int | 微博類型,0全部,1原創,2圖片,3視頻,4音樂. 返回指定類型的微博信息內容。 |
與之相比,騰訊的接口就更原始一些:
請求參數
必選 | 類型及范圍 | 說明 | |
oauth | true | string | oauth標準參數 |
Format | false | string | 返回結果的格式:xml或者json |
Pageflag | false | int | 分頁標示,0表示第一頁,1表示向下翻,2表示向上翻 |
Pagetime | false | int | 本頁起始時間,第一頁填0,繼續翻頁:填上一次請求返回的最后一條記錄時間 |
Reqnum | false | int | 每次請求記錄的條數 |
LastId | false | int64 | 第一頁時填0,繼續向下翻頁,填上一次請求返回的最后一條記錄ID,翻頁用 |
Name | true | string | 你需要讀取的用戶的用戶名 |
我們可以看出,騰訊的接口只提供了翻頁的功能,而新浪則提供了微博過濾。不僅是”獲取微博“這個接口,新浪的大部分API都具備一定程度的信息過濾的能力,而騰訊的大部分接口只提供基本數據。作為第三方的開發者,API接口功能的豐富不僅簡化了開發,也降低了某些應用程序超過API請求限制的風險。
數據完整性
數據完整性是指當開發者請求某種數據時,開放平臺是否對返回數據的數量有所限制。它最能反映一個平臺的開放程度。遺憾的是,從這個意義上講,不論新浪或者騰訊目前為止都沒有做到真正的開放。以獲取一個用戶的”粉絲列表“為例,我們可以看到新浪,騰訊以及Twitter之間的差別。Twitter是一個真正開放的平臺,開發者可以通過API獲取任意用戶的完整粉絲列表。雖然一次請求最多返回100個粉絲的詳細信息,但在Twitter我們可以通過發送多次請求獲得一個完整的粉絲名單。再看新浪,對于一般授權用戶,最多只能獲得5000個最新粉絲信息,但和twitter相比,新浪允許每次請求最多返回200個粉絲。不過,新浪和twitter為開發者還提供了專門的”社交圖譜“接口,一次請求最多獲取一個用戶5000個粉絲的id。只是,新浪仍然將能獲取的粉絲總數設定在5000,而twitter還是一如既往的開放。至于騰訊,其API文檔并沒有限定獲取用戶粉絲的數量,但一次API請求最多只能取得30個粉絲信息,而且也沒有提供類似”社會圖譜“的接口。在這種限制下,想在騰訊微博平臺為一個擁有幾十萬粉絲的用戶構建”社交圖譜“,難度可想而知。
請求限制
很多開發者子在開放平臺上抱怨最多不是API的功能多少,而是每個平臺對于API請求的限制了。但是所有的開放平臺(不論是twitter,linkedin還是facebook)都會一定程度上限制其開發者對自己資源的使用。這與”開放“的策略無關,更多的是基于系統安全性的考慮。因此各個平臺對API的限制策略基本相同,例如,新浪給與普通授權開發者每小時每ip最多1萬次API請求,單個用戶每小時150次請求(騰訊和新浪詳細訪問)。真正的問題不在于一個平臺給與基本授權應用多少請求配額,而在于當一個應用因為配額受到限制的時候,這些平臺能以什么樣的方式去為應用程序解決這個問題。一個平臺只有設計一個公開公平的規則,它才能真正消除開發者對其開放性的懷疑。
通過上面的分析,我們可以清晰的看到新浪是國內目前最接近twitter的微博平臺(從規模和開放性兩個方面),copycat這一次復制的恰到好處。騰訊的微博和twitter相比,完全是另外一個產品。雖然它包含了騰訊對微博和開放平臺自己的理解和計劃,但目前只適合支持以”用戶驅動“的基礎應用。對于“數據驅動”的復雜應用,其平臺的接口暫時還遠不能滿足開發者的需要。
注:本文由深圳樂薦網絡科技有限公司聯合創始人邵寶麟供稿,哥倫比亞大學計算機在讀博士,2007年獲得華中科技大學軟件工程學士學位。曾在印度Infosys SETLab和美國IBM T.J Watson研究中心進行關于“下一代高性能分布計算”的研究。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/