上图是HTTP and Codes部分，可以看到有三个参数可以查看当前请求过程所在的“一轮请求计数”总共的次数、剩余的次数、下次重新计数的时间戳。
注意，HTTP头是上下文的。当使用app-only auth的身份验证时，它们指示应用程序上下文的速率限制。使用user-based auth的身份验证时，它们指示该用户应用程序上下文的速率限制。
当应用程序超过给定标准API终结点的速率限制时，API将返回一个HTTP 429“太多请求”响应代码，并在响应正文中返回以下错误：
为了更好地知道可用的速率限制，请考虑定期使用GET /方法（这两个方法后面会介绍）。
「」的原创文章更好的解释了这几个参数的使用，在此处贴出部分内容：
以“GET /ids”接口为例，文档显示15分钟为一个计数循环，15分钟内单个用户（不同用户请求没有测试）使用“user auth”最多请求15次该接口。计数从每一轮循环的第一次发出请求开始计算本轮循环的15分钟，对应x-rate–reset参数，即为本轮首次发出请求时的时间戳+15*60对应的数字。x-rate-limit-limit对于此接口来说为15（不变的固定值），一轮循环中加入已经请求了N次，则对应的x-rate-limit-为15-N次。
原文链接
GET and POST 请求限制
从系统中读取的速率限制（GET）是根据每个用户和每个应用程序定义的，而写入系统（POST）的速率限制仅在用户帐户级别定义。换句话说，对于读取速率限制，请考虑以下情况：
这部分看不懂也没问题，大概意思是：
对于user auth来说，如果一个用户X，授权了APPa及APPb，分别生成了、，如果使用请求了某个端口（例如GET /list）n次，那么在本轮循环计数结束前使用与请求该端口的剩余次数之和为“15-n”。
避免速率受限的技巧 缓存
如果您希望大量使用API，请将响应存储在您的应用程序或网站中。例如，请勿尝试在网站登录页面的每个页面加载上调用 API。而是不经常调用API，并将响应加载到本地缓存中。当用户访问您的网站时，加载结果的缓存版本。
优先考虑活动用户
如果您的站点跟踪许多用户（例如，获取其当前状态或有关使用情况的统计信息），请考虑仅请求最近登录您站点的用户的数据。
反正最好的突破频率限制的方法还是充钱=。=
