新浪和腾讯微博开放平台比较

从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次请求（腾讯和新浪详细的访问权限请见：http://open.t.sina.com.cn/wiki/index.php/Rate-limiting和 http://open.t.qq.com/resource.php?i=1,3 ）。真正的问题不在于一个平台给与基本授权应用多少请求配额，而在于当一个应用因为配额受到限制的时候，这些平台能以什么样的方式去为应用程序解决这个问题。一个平台只有设计一个公开公平的规则，它才能真正消除开发者对其开放性的怀疑。

通过上面的分析，我们可以清晰的看到新浪是国内目前最接近twitter的微博平台（从规模和开放性两个方面），copycat这一次复制的恰到好处。腾讯的微博和twitter相比，完全是另外一个产品。虽然它包含了腾讯对微博和开放平台自己的理解和计划，但目前只适合支持以”用户驱动“的基础应用。对于“数据驱动”的复杂应用，其平台的接口暂时还远不能满足开发者的需要。