全球第二大社交网站的facebook推出的开发平台在几个月之内迅速走红。在拒绝了 yahoo，google等的收购后，它的狼子野心也暴露无遗，它要做基于web的OS，在它的开放发台上可以搭建集成任何应用。游戏、工作、理财一切都在facebook中了，浏览器+facebook，会成为以后人们的生活方式吗？
然而不得不说facebook的官方文档既乱且差， 很多刚开发facebook应用的人可能都会丈二和尚摸不着头脑。这篇日志算是八卦+tutorial吧。
一、 facebook简介
这段纯属废话，给那些不解facebook， 又不愿意点链接的人看。
Facebook发源于哈佛大学，是目前社会化网络和web2.0的风向标。这个网站目前全球排名第8位，估值可能超过100亿美元。而Facebook开放平台的推出，更是让互联网业内认为它是最有可能和Google比肩的公司。 Facebook创建于2004年2月。这样的高速增长和短短三年多取得的成就，成为当今互联网发展的一个奇迹。
（Facebook 创始人兼CEO Mark Zuckerberg）
这里的介绍更详细：
an/articles/view/thunder/2346
二、facebook platform
2007年5月24日，Facebook推出应用编程接口（API）。通过这个API，第三方软件开发者可以开发在Facebook网站运行的应用程序。这被称为Facebook开放平台（Facebook Platform）。
没有什么比facebook创始人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.
去 www.facebook/apps/ 看看吧， 那里的应用真是应用尽有。
读写网总结的top 10 facebook apps也相当的棒：
adwriteweb/archives/top_10_facebook_apps_work.php
adwriteweb/archives/top_10_facebook_apps_play.php
三、facebook 应用概述
1、平台开发环境
Facebook的开发环境是 LAMP， 这套传统的linux+apache+mysql+php的架构尽管被很多java程序员和ruby程序员所不屑，但它却仍然以绝对的优势占据着主导地位。
不过这对java程序员来说确实有点痛苦，因为facebook官方包装的java client相当的差，更关键的是它没有提供任何java开发web应用的例子和文档。幸亏还有一些非官方的tutorial。地址附在后面。
2、应用集成
谈到应用集成， 我们首先想到的是web services 和SOA，这些被工业界吹了那么多年的buzzword终于得到了推广，然而值得讽刺的是最后web services的推广形式不是他们花了那么多年想出来的SOAP标准，而是最简单又不用任何标准的REST，facebook正是提供了一堆REST的 Web services（从严格意义上说facebook的所有service都是POST过去的，URL也没有完全
遵守REST）。
然而这个层面的集成显然不能满足facebook作为web OS的需要，facebook需要让application运行在它提供的平台上。看看操作系统的需要就能想象到facebook的web OS应用提供怎么的集成。
在windows上我们需要安装应用软件，facebook提供了完整的搜索、浏览、添加 application的方式。
在windows上我们利用各种快捷方式让应用运行在自己的平台里，facebook提供了运行应用的简单入口，而所有的应用都是在facebook内部展示的。
记得前几天看到的一篇文章将应用集成分为三个层面：
1 基于web services和SOA的应用程序交互
2 平台运行在内部服务器上，而各种应用运行在外部服务器上，这正是facebook的方式
3 平台和应用都运行在内部服务器上
但是不知道他有没有想过第三种集成方式的扩展性和伸缩性是多么贫乏，我相信facebook的集成方式才是最好的方式。
jsessionidFacebook 的这篇官方文档解剖了facebook应用集成到平台后的各个界面展示：
developers.facebook/anatomy.php
四、facebook应用种类
Facebook提供了三类的应用：
External application
Iframe       
fbml
1、 external application没什么好说的，就是基于web services的集成，外部应用在经过facebook的认证后可以调用facebook提供的一些web services。
2、 Iframe的集成也相当简单，只是在facebook平台的应用页面上放了个iframe， iframe里跑的是应用程序的应用。好象facebook里的最火的应用之一top friends是用iframe做的。但是由于iframe的天生限制，使它无法完全集成facebook平台提供的功能，如fbml，在页面的显示上也有些怪。
3、目前应用用的最多还是fbml。因为在fbml的应用中，facebook平台的页面（下图所示的菜单部分）和应用程序的页面（如下图黄部分）是无缝显示的，看上去完全象是一个应用做的事。想象成OS的话，外部的菜单栏更象是windows提供的桌面和开始菜单，黄区域则是应用程序。
在fbml应用中，facebook平台主要起着中间人的作用，如下图所示，
所有的用户对facebook平台的请求都被转到了应用的url（在application 里可以配callback url），只不过
是把所有的请求变为post, 同时加上认证必需的一些参数。最后返回的html显示在facebook的application区的canvas里。
但是这个中间人的角并不象想象中的那么简单， 它至少会引起以下问题：
1、httpsession信息丢失，基本上现在的httpsession都依赖于cookie中的jsessionid，但是经过中间人（facebook服务器）后，cookie的信息是无法获取，也意味着 httpsession是无法保存信息的。因此所有的用户相关的信息都是加在中转后的reqeust参数里的，从request里的userId 和sessionKey
应用程序可以重建出用户的所有信息。 不过这倒反而实现了应用的share nothing architectue，对系统的scalability是有好处的。
2、外部css丢失，由于中转的时候只去request callback url里的页面，所有外部的css内容都是干掉的，应用程序只能在html文件里定义css，这对于css狂们真是灾难。
3、 js丢失，facebook会把页面中所有的js给滤掉，而取而代之用自己设计的有限的安全的js语言，这很重要的一部分原因是安全性。但对于ajax狂来说这又是灾难。
五、facebook的authentication
Facebook的认证过程其实不复杂， 但是如果java程序捧着官方提供的java包捣腾，恐怕还要费些功夫，官方那个只提供了桌面应用的认
证程序，而web 应用的认证过程则大厢径庭。
应用程序在注册时会获得该应用的api_key和secret，这实际上是访问该应用的用户名和密码了，只有开发人员可以看到。事实上以后的每次调用facebook api都会带上这api_key，但这显然还不够，登录用户必须拥自己特定的信息：sessionKey，每次调用带上这个key才能将用户的信息关联（类似于tomcat的jsessionid），因此认证的主要目的就是拿到sessionKey。
上图是外部web 应用的认证过程，这种应用只通过web services与facebook集成，这种应用唯一要做的是获得取得调用web services的权限，上图的流程很清楚了。如果用java开发，一般先用一个filter或其它interceptor拦截，如果发现没有登录 facebook应用自动导到facebook的login页面（在request的参数里将登录完后回来的页面传进去），登录后跳回到原来的页面，就可以在filter中通过request里的authtoken获取sessionKey了，这种应用一般将认证后的sessionKey放到 HttpSession就可以了（以后不用重复认证）。
上图是fbml应用的认证过程，事实上内部应用的authentication远比外部应用简单，但是官方竟然没提供文档。由于facebook的用户必须登录才能使用，实际上在使用 facebook应用时用户已经登录并拥有了se
ssionKey和user_id等参数，因此在中间人（facebook server）中转到应用的url时，它在request里会把sessionKey和userId等参数传进去，因此在拿到这些参数后客户端可以直接进行任何web services的调用。
六、facebook api (RESTful web services)
Facebook提供了一堆的api，有认证、用户、相册、好友等功能，从使用的角度来说这倒并不存在什么难点。本身REST的api就是一个httpRequest请求过去返回一个xml的response。经过了官方或非官方的包装以后就变成一个简单的方法调用。
1、所有的api调用都是无状态的，这也是facebook拥有这么好的 scalability的重要原因。每个request里都会带上api_key, session_key, call_id, sig等参数，这保
证了安全性的同时也保证了scalbility。
2、java的客户端调用包比起ruby来实在是恶心多了。这个时候动态语言的优势体现得太明显了。利用ruby的method missing功能，一个简单的实现就可以调用facebook的所有api了，而且扩展性好。Java的包里则定义了一堆恶心方法，而且返回的是一个 xml document， 经过一堆的解析才能取到结果。
七、fql与fbml
Fql就是 facebook版的sql，从使用的角度来说fql的其实挺简单，它只是sql的一个子集， 只支持单表查询，where条件必须是索引过的字段，支持子查询， 还支持一些sql的函数。最简单的例子：
SELECT name, pic FROM user WHERE uid=211031 OR uid=4801660
Fbml是 facebook提供的一堆tag，它只能在fbml的应用程序中使用。从使用的角度来说也很简单，以下html显示了一个用户头像：
<td><fb:profile-pic uid="${friendId}" linked="true" /></td>
八、开发环境                     
开发外部的facebook应用和iframe的facebook应用不需要任何的特殊配置，但是开发fbml的facebook应用却是另一回事了。从第四节的facebook as middleman的图中我们可以看到facebook服务器要读到应用的页面塞到facebook的canvas里。这意味着应用的页面必须是外网可以直接访问才能看到效果。
而我们的开发平台却是搭在本地的， 难道只有部署到服务器上才能看到页面效果？这对开发调是一个严重的挑战。
后悔我当初没有看到这篇blog， 利用SSH的reverse tunnel功能可以将外网的地址按端口号tunnel到本地的开发环境。
blog.evanweaver/articles/2007/07/13/developing-a-facebook-app-locally
我采用另一种方法：增加middleman，facebook本身起了一个中间人的作用，将facebook的请示导到了应用的请求，为什么我们不可以再增加一个中间人， 把外网的请求导到内网？
幸好一个几十行的ruby on rails程序就可以搞定route的功能。
这样实现后的配置也很简单，只要将callback url里的参数映射到本地机器就可以实现多人的同时开发：
urlMap={
[点击图片可在新窗口打开] cc=>'192.168.80.156/facebook/',
:skt=>'192.168.80.133/facebook/'
}
附  facebook平台开发的非官方tutorial：
Ruby 的：
www.liverail/articles/2007/6/29/tutorial-on-developing-a-facebook-platform-application-with-ruby-on-rails
giantrobots.thoughtbot/2007/6/14/fist-in-your-facebook
java的:
uk/2007/07/25/tips-for-writing-facebook-applications-in-java
tmachine1.uk/blog/index.php/2007/08/02/how-to-make-facebook-apps-using-java-part-1/
tmachine1.uk/blog/index.php/2007/08/13/how-to-make-facebook-apps-using-java-part-2/
htt
p://tmachine1.uk/blog/index.php/2007/09/21/ten-tips-and-tricks-for-writing-facebook-app

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。