轉載：http://xiecc.blog.163.com/blog/static/14032200791635949331/
全球第二大社交網(wǎng)站的facebook推出的開(kāi)發(fā)平臺在幾個(gè)月之內迅速走紅。在拒絕了 yahoo，google等的收購后，它的狼子野心也暴露無(wú)遺，它要做基于web的OS，在它的開(kāi)放發(fā)臺上可以搭建集成任何應用。游戲、工作、理財一切都在facebook中了，瀏覽器+facebook，會(huì )成為以后人們的生活方式嗎？
然而不得不說(shuō)facebook的官方文檔既亂且差， 很多剛開(kāi)發(fā)facebook應用的人可能都會(huì )丈二和尚摸不著(zhù)頭腦。這篇日志算是八卦+tutorial吧。
一、facebook簡(jiǎn)介
這段純屬廢話(huà)，給那些不解facebook， 又不愿意點(diǎn)鏈接的人看。
Facebook發(fā)源于哈佛大學(xué)，是目前社會(huì )化網(wǎng)絡(luò )和web2.0的風(fēng)向標。這個(gè)網(wǎng)站目前全球排名第8位，估值可能超過(guò)100億美元。而Facebook開(kāi)放平臺的推出，更是讓互聯(lián)網(wǎng)業(yè)內認為它是最有可能和Google比肩的公司。 Facebook創(chuàng )建于2004年2月。這樣的高速增長(cháng)和短短三年多取得的成就，成為當今互聯(lián)網(wǎng)發(fā)展的一個(gè)奇跡。
（Facebook創(chuàng )始人兼CEO Mark Zuckerberg）
這里的介紹更詳細：
http://www.yeeyan.com/articles/view/thunder/2346
二、facebook platform
2007年5月24日，Facebook推出應用編程接口（API）。通過(guò)這個(gè)API，第三方軟件開(kāi)發(fā)者可以開(kāi)發(fā)在Facebook網(wǎng)站運行的應用程序。這被稱(chēng)為Facebook開(kāi)放平臺（Facebook Platform）。
沒(méi)有什么比f(wàn)acebook創(chuàng )始人mark Zackerberg的總結更好了：
"We want to make Facebook into something of an operating system so you can run full applications," Zuckerberg told me, saying it would be analogous to the platform that Microsoft Windows provides for developers.
去 http://www.facebook.com/apps/ 看看吧， 那里的應用真是應用盡有。
讀寫(xiě)網(wǎng)總結的top 10 facebook apps也相當的棒：
http://www.readwriteweb.com/archives/top_10_facebook_apps_work.php
http://www.readwriteweb.com/archives/top_10_facebook_apps_play.php
三、facebook 應用概述
1、平臺開(kāi)發(fā)環(huán)境
Facebook的開(kāi)發(fā)環(huán)境是LAMP， 這套傳統的linux+apache+mysql+php的架構盡管被很多java程序員和ruby程序員所不屑，但它卻仍然以絕對的優(yōu)勢占據著(zhù)主導地位。
不過(guò)這對java程序員來(lái)說(shuō)確實(shí)有點(diǎn)痛苦，因為facebook官方包裝的java client相當的差，更關(guān)鍵的是它沒(méi)有提供任何java開(kāi)發(fā)web應用的例子和文檔。幸虧還有一些非官方的tutorial。地址附在后面。
2、應用集成
談到應用集成， 我們首先想到的是web services 和SOA，這些被工業(yè)界吹了那么多年的buzzword終于得到了推廣，然而值得諷刺的是最后web services的推廣形式不是他們花了那么多年想出來(lái)的SOAP標準，而是最簡(jiǎn)單又不用任何標準的REST，facebook正是提供了一堆REST的 Web services（從嚴格意義上說(shuō)facebook的所有service都是POST過(guò)去的，URL也沒(méi)有完全遵守REST）。
然而這個(gè)層面的集成顯然不能滿(mǎn)足facebook作為web OS的需要，facebook需要讓application運行在它提供的平臺上?？纯床僮飨到y的需要就能想象到facebook的web OS應用提供怎么的集成。
在windows上我們需要安裝應用軟件，facebook提供了完整的搜索、瀏覽、添加application的方式。
在windows上我們利用各種快捷方式讓?xiě)眠\行在自己的平臺里，facebook提供了運行應用的簡(jiǎn)單入口，而所有的應用都是在facebook內部展示的。
記得前幾天看到的一篇文章將應用集成分為三個(gè)層面：
1 基于web services和SOA的應用程序交互
2 平臺運行在內部服務(wù)器上，而各種應用運行在外部服務(wù)器上，這正是facebook的方式
3 平臺和應用都運行在內部服務(wù)器上
但是不知道他有沒(méi)有想過(guò)第三種集成方式的擴展性和伸縮性是多么貧乏，我相信facebook的集成方式才是最好的方式。
Facebook的這篇官方文檔解剖了facebook應用集成到平臺后的各個(gè)界面展示：
http://developers.facebook.com/anatomy.php
四、facebook應用種類(lèi)
Facebook提供了三類(lèi)的應用：
External application
Iframe
fbml
1、 external application沒(méi)什么好說(shuō)的，就是基于web services的集成，外部應用在經(jīng)過(guò)facebook的認證后可以調用facebook提供的一些web services。
2、 Iframe的集成也相當簡(jiǎn)單，只是在facebook平臺的應用頁(yè)面上放了個(gè)iframe， iframe里跑的是應用程序的應用。好象facebook里的最火的應用之一top friends是用iframe做的。但是由于iframe的天生限制，使它無(wú)法完全集成facebook平臺提供的功能，如fbml，在頁(yè)面的顯示上也有些怪。
3、目前應用用的最多還是fbml。因為在fbml的應用中，facebook平臺的頁(yè)面（下圖所示的菜單部分）和應用程序的頁(yè)面（如下圖黃色部分）是無(wú)縫顯示的，看上去完全象是一個(gè)應用做的事。想象成OS的話(huà)，外部的菜單欄更象是windows提供的桌面和開(kāi)始菜單，黃色區域則是應用程序。
在fbml應用中，facebook平臺主要起著(zhù)中間人的作用，如下圖所示，
所有的用戶(hù)對facebook平臺的請求都被轉到了應用的url（在application 里可以配callback url），只不過(guò)是把所有的請求變?yōu)閜ost, 同時(shí)加上認證必需的一些參數。最后返回的html顯示在facebook的application區的canvas里。
但是這個(gè)中間人的角色并不象想象中的那么簡(jiǎn)單， 它至少會(huì )引起以下問(wèn)題：
1、httpsession信息丟失，基本上現在的httpsession都依賴(lài)于cookie中的jsessionid，但是經(jīng)過(guò)中間人（facebook服務(wù)器）后，cookie的信息是無(wú)法獲取，也意味著(zhù)httpsession是無(wú)法保存信息的。因此所有的用戶(hù)相關(guān)的信息都是加在中轉后的reqeust參數里的，從request里的userId 和sessionKey應用程序可以重建出用戶(hù)的所有信息。 不過(guò)這倒反而實(shí)現了應用的share nothing architectue，對系統的scalability是有好處的。
2、外部css丟失，由于中轉的時(shí)候只去request callback url里的頁(yè)面，所有外部的css內容都是干掉的，應用程序只能在html文件里定義css，這對于css狂們真是災難。
3、js丟失，facebook會(huì )把頁(yè)面中所有的js給濾掉，而取而代之用自己設計的有限的安全的js語(yǔ)言，這很重要的一部分原因是安全性。但對于ajax狂來(lái)說(shuō)這又是災難。
五、facebook的authentication
Facebook的認證過(guò)程其實(shí)不復雜， 但是如果java程序捧著(zhù)官方提供的java包搗騰，恐怕還要費些功夫，官方那個(gè)只提供了桌面應用的認
證程序，而web應用的認證過(guò)程則大廂徑庭。
應用程序在注冊時(shí)會(huì )獲得該應用的api_key和secret，這實(shí)際上是訪(fǎng)問(wèn)該應用的用戶(hù)名和密碼了，只有開(kāi)發(fā)人員可以看到。事實(shí)上以后的每次調用facebook api都會(huì )帶上這api_key，但這顯然還不夠，登錄用戶(hù)必須擁自己特定的信息：sessionKey，每次調用帶上這個(gè)key才能將用戶(hù)的信息關(guān)聯(lián)（類(lèi)似于tomcat的jsessionid），因此認證的主要目的就是拿到sessionKey。
上圖是外部web應用的認證過(guò)程，這種應用只通過(guò)web services與facebook集成，這種應用唯一要做的是獲得取得調用web services的權限，上圖的流程很清楚了。如果用java開(kāi)發(fā)，一般先用一個(gè)filter或其它interceptor攔截，如果發(fā)現沒(méi)有登錄 facebook應用自動(dòng)導到facebook的login頁(yè)面（在request的參數里將登錄完后回來(lái)的頁(yè)面傳進(jìn)去），登錄后跳回到原來(lái)的頁(yè)面，就可以在filter中通過(guò)request里的authtoken獲取sessionKey了，這種應用一般將認證后的sessionKey放到HttpSession就可以了（以后不用重復認證）。
上圖是fbml應用的認證過(guò)程，事實(shí)上內部應用的authentication遠比外部應用簡(jiǎn)單，但是官方竟然沒(méi)提供文檔。由于facebook的用戶(hù)必須登錄才能使用，實(shí)際上在使用 facebook應用時(shí)用戶(hù)已經(jīng)登錄并擁有了sessionKey和user_id等參數，因此在中間人（facebook server）中轉到應用的url時(shí)，它在request里會(huì )把sessionKey和userId等參數傳進(jìn)去，因此在拿到這些參數后客戶(hù)端可以直接進(jìn)行任何web services的調用。
六、facebook api (RESTful web services)
Facebook提供了一堆的api，有認證、用戶(hù)、相冊、好友等功能，從使用的角度來(lái)說(shuō)這倒并不存在什么難點(diǎn)。本身REST的api就是一個(gè)httpRequest請求過(guò)去返回一個(gè)xml的response。經(jīng)過(guò)了官方或非官方的包裝以后就變成一個(gè)簡(jiǎn)單的方法調用。
1、所有的api調用都是無(wú)狀態(tài)的，這也是facebook擁有這么好的 scalability的重要原因。每個(gè)request里都會(huì )帶上api_key, session_key, call_id, sig等參數，這保證了安全性的同時(shí)也保證了scalbility。
2、java的客戶(hù)端調用包比起ruby來(lái)實(shí)在是惡心多了。這個(gè)時(shí)候動(dòng)態(tài)語(yǔ)言的優(yōu)勢體現得太明顯了。利用ruby的method missing功能，一個(gè)簡(jiǎn)單的實(shí)現就可以調用facebook的所有api了，而且擴展性好。Java的包里則定義了一堆惡心方法，而且返回的是一個(gè) xml document， 經(jīng)過(guò)一堆的解析才能取到結果。
七、fql與fbml
Fql就是facebook版的sql，從使用的角度來(lái)說(shuō)fql的其實(shí)挺簡(jiǎn)單，它只是sql的一個(gè)子集， 只支持單表查詢(xún)，where條件必須是索引過(guò)的字段，支持子查詢(xún)， 還支持一些sql的函數。最簡(jiǎn)單的例子：
SELECT name, pic FROM user WHERE uid=211031 OR uid=4801660
Fbml是facebook提供的一堆tag，它只能在fbml的應用程序中使用。從使用的角度來(lái)說(shuō)也很簡(jiǎn)單，以下html顯示了一個(gè)用戶(hù)頭像：
<td><fb:profile-pic uid="${friendId}" linked="true" /></td>
八、開(kāi)發(fā)環(huán)境
開(kāi)發(fā)外部的facebook應用和iframe的facebook應用不需要任何的特殊配置，但是開(kāi)發(fā)fbml的facebook應用卻是另一回事了。從第四節的facebook as middleman的圖中我們可以看到facebook服務(wù)器要讀到應用的頁(yè)面塞到facebook的canvas里。這意味著(zhù)應用的頁(yè)面必須是外網(wǎng)可以直接訪(fǎng)問(wèn)才能看到效果。
而我們的開(kāi)發(fā)平臺卻是搭在本地的， 難道只有部署到服務(wù)器上才能看到頁(yè)面效果？這對開(kāi)發(fā)調是一個(gè)嚴重的挑戰。
后悔我當初沒(méi)有看到這篇blog， 利用SSH的reverse tunnel功能可以將外網(wǎng)的地址按端口號tunnel到本地的開(kāi)發(fā)環(huán)境。
http://blog.evanweaver.com/articles/2007/07/13/developing-a-facebook-app-locally
我采用另一種方法：增加middleman，facebook本身起了一個(gè)中間人的作用，將facebook的請示導到了應用的請求，為什么我們不可以再增加一個(gè)中間人， 把外網(wǎng)的請求導到內網(wǎng)？
幸好一個(gè)幾十行的ruby on rails程序就可以搞定route的功能。
這樣實(shí)現后的配置也很簡(jiǎn)單，只要將callback url里的參數映射到本地機器就可以實(shí)現多人的同時(shí)開(kāi)發(fā)：
urlMap={
:xcc=>'http://192.168.80.156/facebook/',
:skt=>'http://192.168.80.133/facebook/'
}
附 facebook平臺開(kāi)發(fā)的非官方tutorial：
Ruby的：
http://www.liverail.net/articles/2007/6/29/tutorial-on-developing-a-facebook-platform-application-with-ruby-on-rails
http://giantrobots.thoughtbot.com/2007/6/14/fist-in-your-facebook
java的:
http://javablog.co.uk/2007/07/25/tips-for-writing-facebook-applications-in-java
http://tmachine1.dh.bytemark.co.uk/blog/index.php/2007/08/02/how-to-make-facebook-apps-using-java-part-1/
http://tmachine1.dh.bytemark.co.uk/blog/index.php/2007/08/13/how-to-make-facebook-apps-using-java-part-2/
http://tmachine1.dh.bytemark.co.uk/blog/index.php/2007/09/21/ten-tips-and-tricks-for-writing-facebook-apps/
