时下互联网上最流行的莫过于“社交网络”。在国外,烧了投资人无数银子的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研究中心进行关于“下一代高性能分布计算”的研究。
文章来源于领测软件测试网 https://www.ltesting.net/