|
|
| （未显示8个用户的49个中间版本） |
| 第1行： |
第1行： |
| − | ==访问限制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=== | + | <div class="wiki_txtJ"> |
| − | 默认REST API的访问限制是每小时150次，限制分用户和IP, 未授权的访问次数限制主要针对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.
| + | |
| − |
| + | <ul class="wiki_indent_list"> |
| − | 访问限制主要针对HTTP GET请求。发表操作(如发微博)通常是POST操作而不受此限制。
| + | <li clas="wiki_indent_item">• 一个应用内单授权用户每天累计只能请求微博开放接口 100 次；</li> |
| − | 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.
| + | <li clas="wiki_indent_item">• 一个IP地址每小时只能请求微博开放接口 15000 次；</li> |
| − |
| + | <li clas="wiki_indent_item">• 发微博接口单授权用户每小时只能请求 30 次；</li> |
| − | 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:
| + | </ul> |
| − |
| + | |
| − | 1. The account/rate_limit_status method. Calling this method does not count against the requestor's API limit.
| + | 当开发者调用接口不能满足开发需求，且授权用户数高于20万时，欢迎开发者申请合作伙伴洽谈。在保证用户隐私及信息安全的前提下，本着合作、合法、互利的原则，进行深度合作。 |
| − | 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
| + | 合作申请通道：[https://weibo.com/u/1904178193 请私信微博开放平台官方账号] |
| − | * X-RateLimit-Reset the time the current rate limiting period ends in epoch time.
| + | </div> |
| − |
| + | |
| − | ====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.
| + | <div class="wiki_txtJ"> |
| − |
| + | 首先，微博开放接口技术原理上是一个HTTP轮询（polling）协议，不是即时推送（realtime push）协议。因此即使增大刷新频率也无法完全达到即时获得最新信息效果。根据经验，更新频率我们建议3-5分钟/次为宜。 |
| − | 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.
| + | 此外，开发者可以更智能的节省自己的访问频次，比如最近几次拉取数据都没获取到新数据的情况下，可以适当减少访问频率。还可以适当在客户端缓存部分数据，而不是每次都直接调用微博开放接口，但这里需要注意的是，微博开放平台禁止第三方服务器端存储用户数据，所以此方法开发者需注意只能缓存在客户端，不能上传到自己的服务器端。 |
| − |
| + | </div> |
| − | 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==== | + | <div class="wiki_txtJ"> |
| − | 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.
| + | 针对未通过审核的，开发中的应用，我们除了以上的频次限制外，将还有测试账号的额外请求限制。每个未通过审核的应用只能授权15个测试账号来请求接口。除此之外的账号通过该应用，都无法请求接口。当应用通过审核，该限制自动取消。 |
| − |
| + | |
| − | ===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.
| + | 测试账号设置在 <span style="color:#FF7D13;">“我的应用>编辑应用属性>测试账号”</span> 里可以找到。 |
| − |
| + | </div> |
| − | ===黑名单===
| + | |
| − | 我们希望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.
| + | <div class="wiki_txtJ"> |
| − | 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.
| + | |
| | + | 我们希望开发者都能遵循请求限制和微博开放平台的开发者协议，基于用户主动行为正常的访问接口，而不是通过机器人程序、或者非用户主动行为调用接口，甚至大量抓取微博的用户数据。 |
| | + | |
| | + | |
| | + | 因此，超过频次限制的过度调用、或者是非用户主动行为频繁调用（即使未超过频次限制）微博开放接口，都会导致你的应用（appkey）、IP被微博开放平台的安全机制识别为机器人程序、或者恶意抓取用户数据等违反微博开发者协议的情况。从而造成该应用、IP的接口访问权限被封禁，造成所有开放接口的请求都会被限制。 |
| | + | </div> |
| | + | |
| | + | |
| | + | *接口频次限制常见问题请参考 [https://open.weibo.com/wiki/%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98 微博开放平台常见问题] |
| | + | |
| | + | |
| | + | |
| | + | {{#a:nobtns|noheading}} |
| | + | __NOTOC__ |
