社群網路在近來快速崛起,包括台灣流行的Plurk[1]、美日的Twitter[2]和全世界的Facebook[3],在這兩年來皆有突破性的成長。將這些互動經驗與網站結合,善用社群網站所擁有的鏈結與關係,可以有效提昇網站的可見度與宣傳性。對於這個程式開發者不可不知的知識,本文將針對會員人數最多的Facebook的API做一簡介。
背景
社群網路中以Facebook成長最為快速,短短五年間就累積了五億多名會員,爆炸性成長背後的主要原因就在於『好友關係』,朋友們彼此間成立密不可分的社群關係,使Facebook的使用人數以指數性的曲線往上衝升。也正因如此的型態與關連,許多創新的行銷手法一一出現,正所謂『朋友的分享不是廣告』,許多網站、新聞都藉著這種分享紅極一時,甚至有人稱之為『病毒行銷』,指出在Facebook上的宣傳有如病毒一般擴散的非常快速。因此,Facebook的出現,不僅僅提供了使用者彼此間聯繫感情的管道,更重新定義了企業、網站與使用者互動的方式。根據統計,光是每天在Facebook上『按讚』分享文章的使用者可能就超過六千五百萬人次。
Facebook API
Facebook API可以應用在多種環境下,包括網站(Website)、Facebook應用程式(Apps on Facebook.com)以及行動應用程式(Mobile Apps)。根據不同的平台,Facebook也提供了不同的SDK(Software Development Kit)給開發者使用,包含了網站上使用的JavaScript SDK、PHP & Python SDK,以及行動裝置上的iOS SDK(iPhone & iPad)、Android SDK等,可以說無論在哪個平台上皆可看到Facebook API的身影。
使用Facebook API並不困難,甚至有越來越簡易的趨勢。在過去一兩年間,由於將Facebook API用在網站上的使用人數大幅增加,Facebook也將常用到的一些服務包裝成套件供開發者直接套用(Facebook稱之為Social Plugin),其中包含最常見的『按讚』、『朋友的動態』、『留言系統』…等。若一般網站開發者需要使用這些功能,只要到Facebook開發者網頁填寫一些必要的資訊(appID、plugin的寬度、回傳url…等),Facebook便會自動替開發者產生相對應的plugin程式碼,接著開發者只需要將這些程式碼嵌入網頁中就大功告成了!而在筆者截稿之前,Facebook甚至開放『留言』(comment) API,進一步將Facebook的互動融入在各個網站中。
但無論Facebook提供各種API,追根究柢,其實大家想要使用Facebook API的目的終究是希望能夠擷取使用者以及與使用者相關的一些物件(朋友、網頁…等)之間的鏈結,也因此Facebook將這個概念濃縮成為一個核心概念,稱之為Social Graph。而存取這些關係的API,就稱之為Graph API。依照Facebook在官方文件上對於Graph API的說明如下:Graph API提供了可以一窺社群網路的方法,並提供物件本身的資訊以及物件間彼此的鏈結關係。這邊所提到的物件,其實在Facebook裡的定義是非常廣泛的,舉凡人、照片、事件、網頁都可以是一個物件。而鏈結關係就是這些物件間彼此的關係,例如人跟人之間的關係(朋友/非朋友)、人跟照片的關係(人擁有某些照片、照片上的標籤屬於某些人等)、人跟事件與網頁的關係(讚)...等。因此其實也可以說,任何你需要Facebook提供的資訊,Graph API幾乎都能滿足你的需求。
http://graph.facebook.com/austintodo
舉例來說,基本的Graph API可以得知某個物件的資訊。若我想要知道某個人(以我為例,Facebook帳號名稱為austintodo)的基本資訊,開發者可以直接向Graph API詢問關於austintodo的相關資訊(http://graph.facebook.com/austintodo),Facebook就會將austintodo這位使用者個人公開的資訊回傳給開發者。簡而言之,若開發者需要任何物件(如同上述的『物件』,人、照片、事件、網頁皆視為物件)的相關資訊,只需要向Graph API丟出一個請求即可(例如:coca-cola的事件相關資訊,就可以丟出https://Graph.Facebook.com/cocacola這樣的請求)。而進一步來說,若開發者需要知道物件與物件之間的鏈結時,則只需要指名物件的ID以及鏈結的形態即可,並透過這樣的結構:https://Graph.Facebook.com/ID/CONNECTION_TYPE向Facebook索取即可[4]。
而若上述的方式無法滿足開發者的需求,Facebook更提供了一套類似SQL的查詢方式,稱為FQL。如同SQL,FQL的標準使用方式為:SELECT [fields] FROM [table] WHERE [conditions],fields為id, name, pictures..等,table為user, album, comment…等,conditions則試開發者需求自行設定。[5]
然而,提供了如此多樣化的API以及豐富的資訊,不禁讓社會大眾開始關切隱私權的議題。若任何一個開發者都可以藉由輸入ID以及鏈結型態就可以拿到某個物件的關係圖,那麼用戶的隱私蕩然無存。因此Facebook也提供了授權(authorization)機制:任何可能擷取到關於隱私的資料時,在Graph API的請求中應該要附加一個存取鑰匙(access token)。如此一來若這些app想存取某些隱私資料時,必須經過Facebook的授權以及使用者的認可後才可開放存取。
Facebook採用OAuth2.0認證方式,總共有三個步驟:使用者認證(user authentication)、app授權(app authorization)、app認證(app authentication)。使用者認證:確保使用者即為使用者本人;app授權:向使用者確認他們即將授權此app拿到這些隱私資料;app認證:確保使用者授權的app就是目前這個app。經過這三階段的認證後,app即可從Facebook得取存取鑰匙(access key),而之後向Graph API索取資料時,只需要將access token附加在Graph API請求後即可(如:https://Graph.Facebook.com/me?access_token=ACCESS_TOKEN)
結語
總括來說,在這樣一個社群統治的資訊時代裡,Web 2.0的概念已經不敷使用。網友們不會再相信雜亂無章的資訊,而是死心踏地的忠誠於朋友的推薦;不會再透過google搜尋有趣的新聞,而是從Facebook塗鴉牆內看遍世界。如此的情況對傳統網站是種危機,卻也是轉機。若不懂適度的調整網站內容、使用方式,那麼Web 3.0的潮流很快就會淘汰過於陳舊的網路資訊;若是懂得借力使力、調整風帆,那麼病毒式的社群行銷將會是提高網站拜訪率的得力助手!
參考文獻與相關連結
[1] http://www.plurk.com/
[2] http://twitter.com/
[3] http://www.facebook.com/
[4] Facebook API document, http://developers.facebook.com/docs/reference/api/
[5] FQL, http://developers.Facebook.com/docs/reference/fql/