微博开放平台
微连接
移动应用
网站接入
电商服务商
电商商家
数据服务
数据服务
合作伙伴
微博支付
轻应用
粉丝服务
文档
推广
我的应用
登录
weibo
开发文档
首页
平台政策与指引
概述
平台公约
新手指南
开发者协议
应用运营管理规范
微连接分级管理办法
应用审核产品指南
应用安全开发注意事项
平台应用设计规范
微服务接入指南
微博登录接入
用微博帐号登录
授权机制
移动应用接入
移动应用介绍
移动应用SSO授权
微博Deep Link
媒体接入平台
头条文章开放接口
视频上传开放接口
电商接入平台
电商服务商接入
电商商家端接入
电商平台能力接口
粉丝服务平台
粉丝服务平台
新手接入指南
微信开发者迁移指南
接收消息
发送消息
自定义菜单
用户管理
生成带参数的二维码
Fans Service Platform
商业接口
商业数据接入指南
订阅服务手册(中文版)
订阅服务手册(英文版)
商业接口-REST API
商业数据常见问题
网站接入
网站接入介绍
微博API
微博API
接口访问频次权限
资源下载
SDK
微博标识下载
常见问题
联系我们
工具箱
链入页面
链出更改
特殊页面
查看源代码
跳转到:
导航
,
搜索
根据下列原因,你没有权限编辑本页:
您刚才请求的操作只有这个用户组中的用户才能使用:
用户
您可以查看并复制此页面的源代码:
==访问限制Rate limiting== 微博API限制客户端每小时只能执行有限个请求。详述如下。 The miniblog API only allows clients to make a limited number of calls in a given hour. This policy affects the two APIs in different ways. ===REST API Rate Limiting=== 默认REST API的访问限制是每小时150次,限制分用户和IP, 未授权的访问次数限制主要针对IP,登录后的请求访问限制主要针对用户。 The default rate limit for calls to the REST API is 150 requests per hour. The REST API does account- and IP-based rate limiting. Authenticated API calls are charged to the authenticating user's limit while unauthenticated API calls are deducted from the calling IP address' allotment. 访问限制主要针对HTTP GET请求。发表操作(如发微博)通常是POST操作而不受此限制。 Rate limiting only applies to methods that request information with the HTTP GET command. API methods that use HTTP POST to submit data to miniblog, such as statuses/update do not affect rate limits. Additionally, requests to account/rate_limit_status are not charged to a limit. These unlimited methods are still subject to daily update and follower limits to promote healthy use and discourage spam. Your application should recognize it is being rate-limited by the REST API if it receives begins to receive HTTP 400 response codes. It is best practice for applications to monitor their current rate limit status and dynamically throttle requests if necessary. The REST API offers two ways to observe this status: 1. The account/rate_limit_status method. Calling this method does not count against the requestor's API limit. 2. HTTP response headers included in all REST API responses which count against the rate limit: * X-RateLimit-Limit the current limit in effect * X-RateLimit-Remaining the number of hits remaining before you are rate limited * X-RateLimit-Reset the time the current rate limiting period ends in epoch time. ====Whitelisting==== Some applications find that the default limit proves insufficient. Under such circumstances, we offer whitelisting. It is possible to whitelist both accounts and IP addresses. Each whitelisted entity, whether an account or IP address, is allowed 20000 requests per hour. If you are developing an application that should be considered for whitelisting, please fill out the whitelisting request form. Our manual review process can take up to a week. If you have a whitelisting that needs to be updated through the addition or removal of IP addresses, reapply with an explanation of the change. Approval or rejection for whitelisting requests is emailed to the email address associated with the account that filed the application. IP whitelisting takes precedence to account rate limits. GET requests from a whitelisted IP address made on a user's behalf will be deducted from the whitelisted IP's limit, not the users. Therefore, IP-based whitelisting is a best practice for applications that request many users' data. Whitelisting does not removed the daily update and follower limits associated with POST requests; these limits are administered on a per account basis. If you have received verification from miniblog that your account and/or IP address has been whitelisted you can verify your whitelisting with the accounts/rate_limit_status method. Calling this method with credentials will return the rate limit status of the authenticating user and invoking this method without credentials will return the rate limit status of the calling IP address. ===Search API Rate Limiting(暂不支持)=== The Search API is rate limited by IP address. The number of search requests that originate from a given IP address are counted against the search rate limiter. The specific number of requests a client is able to make to the Search API for a given hour is not released. Note that the Search API is not limited by the same 150 requests per hour limit as the REST API. The number is quite a bit higher and we feel it is both liberal and sufficient for most applications. We do not give the exact number because we want to discourage unnecessary search usage. Search API usage requires that applications include a unique and identifying User Agent string. A HTTP Referrer is expected but is not required. Consumers using the Search API but failing to include a User Agent string will receive a lower rate limit. An application that exceeds the rate limitations of the Search API will receive HTTP 503 response codes to requests. It is a best practice to watch for this error condition and honor the Retry-After header that instructs the application when it is safe to continue. The Retry-After header's value is the number of seconds your application should wait before submitting another query (for example: Retry-After: 67). ====Whitelisting==== There is no general idea of a whitelist for the Search API as with the REST API. However, under extraordinary circumstances we work with developers to raise rate limiting for Search requests. We do not give preemptive whitelisting for the Search API. You must have a working application that has proven need (users) for more capacity before we will discuss whitelisting. If you feel that your application is doing everything it can to limit and combine queries where appropriate, please contact miniblog to discuss your needs. The Search API is only able to whitelist IP addresses, not user accounts. This works in most situations but for cloud platforms like Google App Engine, applications without a static IP addresses cannot receive Search whitelisting. ===Avoiding the Rate Limiter=== The same general techniques and design decisions can be used to avoid the crunch of the rate limiter. 1. Caching: Store API responses in your application or on your site if you expect high-volume usage. For example, don't try to call the miniblog API on every page load of your hugely popular website. Instead, call our API infrequently, cache the response on your end, and display the local version on page loads. 2. Prioritize active users: If your site keeps track of many miniblog users (for example, fetching their current status or statistics about their miniblog usage), consider only requesting data for users who have recently signed into your site. 3. Search back-offs: If your application monitors a high volume of search terms, query less often for searches that have no results than for those that do. By using a back-off you can keep up to date on queries that are hot but not waste cycles requesting queries that very rarely change. ===黑名单=== 我们希望API调用者都能遵循请求限制,过度频率的调用API会导致你的应用/IP加入黑名单。加入黑名单之后,所有请求都会无任何返回。 If your application has been blacklisted and you would like service reinstated please do the following: 1. If you are using the REST API, make a call to the account/rate_limit_status from the account or computer in question. 2. Explain why you think your application was blacklisted. 3. Describe how you have fixed the problem that resulted in blacklisting. Send that information in an email to our support folks so we can get you back online.
返回到
Rate-limiting
。
反馈
分享
顶部