Rate-limiting

跳转到: 导航, 搜索
(开发者如何正确面对频率限制)
第2行: 第2行:
 
微博接口限制用户每个小时只能请求一定的次数。限制分用户维度和IP维度,详述如下:
 
微博接口限制用户每个小时只能请求一定的次数。限制分用户维度和IP维度,详述如下:
  
===针对一个服务器IP的请求次数限制===
+
 
 +
<b class="W_f14">一、针对一个服务器IP的请求次数限制</b>
 +
 
 
<span style="color:#FF7D13;">测试授权:</span>
 
<span style="color:#FF7D13;">测试授权:</span>
 
**1000次/小时
 
**1000次/小时
第18行: 第20行:
 
**40000次/小时
 
**40000次/小时
  
===针对一个用户在使用一个应用的请求次数限制===
+
 
 +
<b class="W_f14">二、针对一个用户在使用一个应用的请求次数限制</b>
 +
 
 
<span style="color:#FF7D13;">测试授权:</span>
 
<span style="color:#FF7D13;">测试授权:</span>
 
**总限制:单用户每应用 150次/小时
 
**总限制:单用户每应用 150次/小时
**发微博:单用户每应用 30次/小时
+
**发微博:单用户每应用 15次/小时 50次/天
**发评论:单用户每应用 60次/小时
+
**发评论:单用户每应用 15次/小时 50次/天
**加关注:单用户每应用 60次/小时  100次/天
+
**加关注:单用户每应用 15次/小时  50次/天
  
<span style="color:#FF7D13;">普通授权:</span>
+
<span style="color:#FF7D13;">普通授权、中级授权、高级授权:</span>
**总限制:单用户每应用 1000次/小时
+
**总限制:单用户每应用 2000次/小时
**发微博:单用户每应用 30次/小时
+
**发微博:单用户每应用 60次/小时
 
**发评论:单用户每应用 60次/小时
 
**发评论:单用户每应用 60次/小时
 
**加关注:单用户每应用 60次/小时  200次/天
 
**加关注:单用户每应用 60次/小时  200次/天
 
<span style="color:#FF7D13;">中级授权:</span>
 
**总限制:单用户每应用 1500次/小时
 
**发微博:单用户每应用 60次/小时
 
**发评论:单用户每应用 120次/小时
 
**加关注:单用户每应用 120次/小时  300次/天
 
 
<span style="color:#FF7D13;">高级授权:</span>
 
**总限制:单用户每应用 2000次/小时
 
**发微博:单用户每应用 90次/小时
 
**发评论:单用户每应用 180次/小时
 
**加关注:单用户每应用 180次/小时  300次/天
 
  
 
<span style="color:#FF7D13;">合作授权:</span>
 
<span style="color:#FF7D13;">合作授权:</span>
第70行: 第62行:
 
{{center|http://www.sinaimg.cn/blog/developer/wiki/jkpc03.jpg}}
 
{{center|http://www.sinaimg.cn/blog/developer/wiki/jkpc03.jpg}}
  
===未通过审核应用的测试账号限制===
+
 
 +
<b class="W_f14">三、未通过审核应用的测试账号限制</b>
 +
 
 
针对未通过审核的,开发中的应用,我们除了以上的频次限制外,将还有测试账号的额外请求限制。每个未通过审核应用只能授权15个测试账号来请求接口。除此之外的账号通过该应用,都无法请求接口。当应用通过审核,该限制自动取消。
 
针对未通过审核的,开发中的应用,我们除了以上的频次限制外,将还有测试账号的额外请求限制。每个未通过审核应用只能授权15个测试账号来请求接口。除此之外的账号通过该应用,都无法请求接口。当应用通过审核,该限制自动取消。
  
第77行: 第71行:
  
 
<div style="display:none;">
 
<div style="display:none;">
===需要授权的接口限制===
+
 
 +
 
 +
<b class="W_f14">需要授权的接口限制</b>
 +
 
 
微博平台的<span style="color:#FF7D13;">私信接口、搜索接口</span>默认为限制接口。
 
微博平台的<span style="color:#FF7D13;">私信接口、搜索接口</span>默认为限制接口。
 
</div>
 
</div>
  
===黑名单===
+
 
 +
<b class="W_f14">四、黑名单</b>
 +
 
 
我们希望API调用者都能遵循请求限制,过度频率的调用API会导致你的应用/IP加入黑名单。加入黑名单之后,所有请求都会无任何返回。
 
我们希望API调用者都能遵循请求限制,过度频率的调用API会导致你的应用/IP加入黑名单。加入黑名单之后,所有请求都会无任何返回。
  
==开发者如何正确面对频率限制==
+
 
 +
<b class="W_f14">五、开发者如何正确面对频率限制</b>
 +
 
 
首先微博API技术原理上是一个HTTP轮询(POLLING)协议,不是即时推送(realtime push)协议。因此即使增大刷新频率也无法完全达到即时获得最新信息效果。根据经验,更新频率我们建议2-3分钟/次为宜,API客户端也可提供一个手工刷新按钮,用户可以手工获取最新数据。
 
首先微博API技术原理上是一个HTTP轮询(POLLING)协议,不是即时推送(realtime push)协议。因此即使增大刷新频率也无法完全达到即时获得最新信息效果。根据经验,更新频率我们建议2-3分钟/次为宜,API客户端也可提供一个手工刷新按钮,用户可以手工获取最新数据。
 
   
 
   
第91行: 第92行:
  
  
客户端可以通过以下接口查询当前剩余请求数[[Account/rate_limit_status]]
+
*客户端可以通过以下接口查询当前剩余请求数:[[Account/rate_limit_status]]
  
接口频率限制常见问题请参考 [http://open.weibo.com/qa 微博开放平台问答系统]
+
*接口频率限制常见问题请参考 [http://open.weibo.com/qa 微博开放平台问答系统]

2014年3月21日 (五) 10:43的版本

接口访问频次权限

微博接口限制用户每个小时只能请求一定的次数。限制分用户维度和IP维度,详述如下:


一、针对一个服务器IP的请求次数限制

测试授权:

    • 1000次/小时

普通授权:

    • 10000次/小时

中级授权:

    • 20000次/小时

高级授权:

    • 30000次/小时

合作授权:

    • 40000次/小时


二、针对一个用户在使用一个应用的请求次数限制

测试授权:

    • 总限制:单用户每应用 150次/小时
    • 发微博:单用户每应用 15次/小时 50次/天
    • 发评论:单用户每应用 15次/小时 50次/天
    • 加关注:单用户每应用 15次/小时 50次/天

普通授权、中级授权、高级授权:

    • 总限制:单用户每应用 2000次/小时
    • 发微博:单用户每应用 60次/小时
    • 发评论:单用户每应用 60次/小时
    • 加关注:单用户每应用 60次/小时 200次/天

合作授权:

    • 总限制:单用户每应用 无限制
    • 发微博:单用户每应用 120次/小时
    • 发评论:单用户每应用 240次/小时
    • 加关注:单用户每应用 240次/小时 300次/天


未通过审核的,开发中的应用,将适用测试授权,当应用通过审核成为正式应用,将自动升级为普通授权。


客户端类应用最高可申请至合作伙伴授权(授权有效期90天)级别,网页类应用、网站接入类应用最高可申请至高级授权(授权有效期30天)级别。


当频次权限达到本级别的上限时,可在应用控制台中,接口管理标签下的调用频次选项中进行在线申请。

jkpc01.jpg


申请时请详细填写应用的产品介绍、推广策略和改进目标。

jkpc02.jpg


申请成功后请等待审核,三个工作日之内反馈结果。

jkpc03.jpg


三、未通过审核应用的测试账号限制

针对未通过审核的,开发中的应用,我们除了以上的频次限制外,将还有测试账号的额外请求限制。每个未通过审核应用只能授权15个测试账号来请求接口。除此之外的账号通过该应用,都无法请求接口。当应用通过审核,该限制自动取消。


测试账号设置在 “我的应用>编辑应用属性>测试账号” 里可以找到。


需要授权的接口限制

微博平台的私信接口、搜索接口默认为限制接口。


四、黑名单

我们希望API调用者都能遵循请求限制,过度频率的调用API会导致你的应用/IP加入黑名单。加入黑名单之后,所有请求都会无任何返回。


五、开发者如何正确面对频率限制

首先微博API技术原理上是一个HTTP轮询(POLLING)协议,不是即时推送(realtime push)协议。因此即使增大刷新频率也无法完全达到即时获得最新信息效果。根据经验,更新频率我们建议2-3分钟/次为宜,API客户端也可提供一个手工刷新按钮,用户可以手工获取最新数据。


API客户端可以智能控制请求频率,比如最近几次更新都没获取到数据情况下可以适当将间隔时间延长。当一小时内剩余次数多时候可以适当将更新加快。当剩余请求数偏小时,客户端通过延长自己的更新频率控制不超过上限。另外要适当留一些空余指标,防止用户手工执行一些操作产生的调用导致超出上限。