• Email:
  • Feeds

  • Archive for the ‘SNS’ Category


    Twitter API最近的一些飞跃

    Twitter的平台总监Ryan Sarver在最近一封给开发者公开email Platform announcements from LeWeb提到,打算将API用户请求限制扩大10倍,由目前的150次/小时扩大到1,500次/小时(但同时将搜索范围缩短到7天)。

    *Auth announcements*
    With the recent launches of Retweet, Lists and Geotagging we have seen
    applications struggle to provide the experience they want for their users
    within the 150 req/hr limit. We are excited to open the skies up a bit and
    provide some more room for developers to work within. Starting in a few
    weeks all OAuth requests to api.twitter.com/1/ will be able to take
    advantage of a 10x rate limit increase. Basic Whitelisting still exists and
    is unchanged. We look forward to what this means in terms of the increased
    richness around the user experience in Twitter apps.

    注意文中的限制是OAuth客户端,为什么只限OAuth客户端?由于OAuth客户端可控性较强。如果发现app有滥用api嫌疑,可以直接suspend这个app;而另外一种鉴权方式Basic Authentication方式并不强制client传递app id, 服务器判断app abuse较困难。

    在我的理解,microblog的最大的特性应该是realtime,(另外一特性应是social graph), 即使Twitter扩大rate limit, REST方式的HTTP协议终究没法实现realtime,如果所有的客户端都1分钟请求25次(1,500/60=25),twitter服务器稳定性一向声誉不佳,增大后能否经住考验也是一个疑问。

    如果要实现真正的realtime, 目前有http callback或者XMPP等方案。callback由于客户端通常在防火墙内并不可行。XMPP由于协议栈庞大,服务端及客户端编写都比较繁琐,而且XMPP是为IM协议设计,所以并不十分适合twitter api。

    另外Twitter在邮件中还提到,打算将所有最新更新feed的数据流(Twitter称为Firehose)向所有人开放。

    *Firehose for everyone*
    Finally, the announcement that has garnered the most coverage and
    excitement. As I stated in the session at LeWeb we are committed to
    providing a framework for any company big or small, rich or poor to do a
    deal with us to get access to the Firehose in the same way we did deals with
    Google and Microsoft. We want everyone to have the opportunity — terms will
    vary based on a number of variables but we want a two-person startup in a
    garage to have the same opportunity to build great things with the full feed
    that someone with a billion dollar market cap does. There are still a lot of
    details to be fleshed out and communicated, but this a top priority for us
    and we look forward to what types of companies and products get built on top
    of this unique and rich stream.

    Firehose可以理解成所有Twitter最近更新的水龙头,目前只对 Microsoft, Google等少量公司开放。Twitter表示以后即使”a two-person startup in a garage”这样的公司也可以获取firehose访问权限, “We want everyone to have the opportunity”。相信不少公司将会为这一特性而激动甚至疯狂。firehose开放意味为第三方提供了无限的创意空间,另外它也会对Twitter已有的服务search, geotag等业务构成威胁,走出这一步需要很大的勇气。

    以上文字基本已在新浪微博发表过,整理后就成了一篇blog, 欢迎在新浪微博关注我,点这里进入 http://t.sina.com.cn/timyang

    Facebook平台设计(二)

    上个月介绍了Facebook平台设计(一),再继续看f8 2008。f8平台推出在短短一年的应用开发者已经超过40万。keynote继续由Facebook创始人兼CEO Mark Zuckerberg主持(视频),Mark介绍了一年中不少成功的应用案例,如iLike推出4天就增长到100万用户,以及 livingsocial, Zynga等成功案例。主要的议题包括

    一、Facebook Connect

    Facebook开放平台之后围墙的问题依然存在,所有的用户所有的内容都在facebook网站的内部。facebook connect可以将facebook的用户,好友,feed和第三方网站作深度整合。将social graph扩大到所有的Web领域。到目前为止Facebook Connect的应用已经非常广泛,比如6月27号的Facebook Developer Garage Shanghai介绍了不少基于Facebook Connect的网站,如提供给外国人分享在上海活动图片的citymoments就非常不错。

    二、Facebook新的设计

    Mark介绍了很多Facebook新的设计, 比如应用可以不再局限在profile box里面,可以作为一个独立的profile tab, 相当一个独立的页面,应用开发商有更多独立的发挥空间。
    另外facebook开放了翻译工具, facebook的翻译工具可以让全球的用户帮助将第三方开发的应用翻译成各种本地语言,并由用户投票每个条目最合适的翻译结果。这个本来用于facebook平台自身的国际化,此次开放给第三方开发者。

    三、平台指导原则

    f8 keynote后半部分由Benjamin Ling主讲(视频),Ben也是一位神奇的人物。他本来在Google当产品总监,2007年跳槽到facebook做Director of Platform, 不过好像现在又跑回youtube去了。Ben是亚洲面孔,不知道是不是华人。他介绍了facebook平台的三大指导原则(Guide principle for great social app)

    1. meaningful/有意义
    a. social(graph), e.g. Green Patch
    b. useful/有用,如Carpool
    c. Expressive/表达, Graffiti, draw on friend profile
    d. Engaging, 比如2008/5,用户投入在playfish上的时间有9亿分钟。

    2. trustworthy/信任
    safe/安全, trusted
    secure – 平台越提供更多的privacy控制, 用户才会产生越多内容
    respectful
    transparent

    3. well designed/良好的设计
    clean, facebook平台确实很干净,值得陈赞, 因此平台要求应用也如此。
    fast, use more, 访问速度越快,用户用得越多。
    robust, 强壮

    原则总结起来就一句话,”keep the ecosystem safe for user, fair for developers“, 平台设计的目标是对用户安全,对开发者公平。

    国内开放API平台实践的一些问题

    随着在国外一些开放API的成功,国内开放的趋势尤其是在SNS领域也开始涌现,实际上开放的需求不局限SNS领域,所有的互联网应用都可以从开放API获得更多的用户使用等潜在的价值。Tim在这方面也进行了一些尝试和思考,这里初步探讨开放API产品及开发方面实践中需要面对的几个问题。

    一、设计开放API没有明显的标准可以遵循

    • 如何设计一个好的鉴权(authentication)体系,安全,便利,简单。
    • 如何设计一个好的用户SSO(Single Sign-On)体系,达到无缝的在第三方网站与平台之间切换,或者支持将平台的内容无缝嵌入第三方网站,类似facebook connect这样的体系。
    • 国外的一些标准是否适合引进,比如OpenIDOAuth,OpenID国内还没有成功案例或领头羊,因此支持OpenID的用途就大打了折扣。OAuth解决了平台对第三方应用的信任(authorization)问题,但对于国内的第三方开发者是否太复杂。

    二、缺少深度理解开放平台设计的产品及开发人员

    国内大部分从业人员可能都没一手接触国外的开放平台产品及API,可能没写过一个hello world的Facebook应用,说不出Gadget的原理或者理解twitter client跟服务器交互的具体流程。大部分从业人员可能简单的理解facebook就是开心网一样。因此即使有意愿也很难设计出能真实满足用户需要的接口。

    三、没有生态圈或者短期不能形成生态圈

    Facebook的魅力就是从f8 2007推出到2008 f8已经形成40万开发者的规模,这40万开发人员对Facebook Platform的稳定及成熟起了非常重要的作用。但对于国内每一个新的开放平台可能设计人员并不清楚下游开发者在哪里,也很难进一步了解潜在的需求,很容易造成闭门造车的局面。

    四、不清楚盈利模式

    由于找不到清晰的赢利模式,不但对于提供平台的公司还是对于下游的开发者都缺乏推动力,所以大部分公司都是抱着试试看的心态去公开一些非核心的API。另外平台本身也有顾虑开放API是否会对本身原有的业务带来冲击,因此在公司内部也不太容易得到大力的支持,所以都是在小圈子内充当着试验田的角色。