错误429，请求过多：对价格进行限制后该怎么办？

您的应用程序运行平稳。 测试通过了。 突然，您开始看到来自API的429错误响应。 顾名思义，您发出了太多请求，并且您的应用程序受到速率的限制。 429（请求过多）错误是当您遇到API的请求限制时经常发生的HTTP状态代码 。

虽然速率限制在您遇到时似乎是一件坏事，但此限制是大多数可消耗API的保护功能。 速率限制可防止服务受到故意滥用以及开发人员测试应用程序时可能发生的意外滥用。 如果您将水倒入漏斗的速度太快，您会看到它开始倒流并最终溢出。 速率限制旨在通过在问题出现之前停止请求流来防止这种情况。

那么，作为使用API​​的开发人员，您 能做什么呢？ 首先，让我们看一下导致错误的原因以及如何找到API的速率限制详细信息。

速率限制阈值及其触发方式

根据您所构建的应用程序类型的不同，可能会遇到多种情况，例如速率限制。 漫游器以及持续轮询API的任何应用程序最有可能遇到该错误。 直接让用户与第三方API交互的应用程序也有更高的达到极限的风险。 要了解有关API速率限制阈值的更多信息，最好查看正在使用的API的文档。

通常，速率限制由一段时间内的请求定义。 例如， GitHub的v3 REST API对于每个已认证的请求，每个已认证的用户每小时限制5000个请求。 对于未经身份验证的请求，该限制为每小时60个请求。 这些类型的限制可以是API范围的，也可以是端点或资源唯一的。 例如， Discord API对每个端点和帐户都有唯一的限制。 因此，您应该避免将限制直接硬编码到应用程序中。

要记住的另一件事是，这些基于时间的限制可能是基于第一个请求的时间设置的，或者可能具有固定的时间范围，例如一天的开始。

尽管许多服务将像上面的GitHub示例中那样发布其限制，但其他服务可能会将限制包括为响应的属性，或者甚至是仅在达到限制时才显示的标头。

了解429错误响应

您已经看到了错误代码，但是当请求失败时，通常会有更多可用信息。 REST API通常会包括一条描述问题的消息以及一组X-RateLimit- *标头，其中包含有关限制的信息。 某些API（例如GitHub的API）也将在成功请求中包含此API。 每个API都有自己的特定标头，但是一些与速率限制相关的标头是：

X-RateLimit-Limit：可以发出的请求数量（跨时间段）X-RateLimit-Remaining：可以发出的剩余请求数量（跨时间段）.X-RateLimit-Reset ：重设限制的时间戳。

GraphQL API将在达到限制时返回错误，例如Yelp的GraphQL API ，或者可以提供一种检查当前用法的方法。 GitHub的v4 Graph API通过允许用户查询rateLimit对象来做到这一点。

<code class=" language-graphql" style="box-sizing: inherit; margin: 0 px; padding: 0 px; border: 0 px; font-style: inherit; font-variant: inherit; font-weight: 400 !important ; font-stretch: inherit; line-height: inherit; font-family: Consolas, Monaco, &quot;Andale Mono&quot;, &quot;Ubuntu Mono&quot;, monospace; font-size: inherit; vertical-align: baseline; background: transparent; border-radius: 3 px; color: rgb(248, 248 , 242 ); text-shadow: rgba(0, 0 , 0 , 0.3 ) 0 px 1 px; text-align: left; white-space: pre; word-spacing: normal; word-break: normal; overflow-wrap: normal; tab-size: 4 ; hyphens: none;">query {
  rateLimit {
    limit
    cost
    remaining
    resetAt
  }
}
</code>

这些先发制人的方法使您可以在达到限制之前执行检查，而不仅仅是对错误做出反应。

如何修复“请求过多”错误

如果API为您提供了包含重置信息的标头或错误对象，则可以使用它在重新尝试之前等待适当的时间。 使用resetAt-currentTime并使用它在发出另一个请求之前等待。 您甚至可以将此功能带到断路器中 ，或者使用Bearer之类的解决方案在某些条件下重试。

如果没有以编程方式知道尝试等待多长时间，则可以使用“退避”方法，其中代码执行一系列重试，每次重试之间的延迟增加。

如何真正避免429错误

这些方法不错，但是如果您提供的API达到了其他API的速率限制，该怎么办？ 在这种情况下，您将希望限制对API的传入调用，以防止速率限制引起问题。 节流是一种限制代码执行的技术。 在这种情况下，请求将受到限制，并使用缓存的数据“丢弃”或满足请求。 这样，您的应用就会在第三方服务达到极限之前进行干预。 这种方法对于限制昂贵API的使用也很有用。 您甚至可以使用更保守的阈值来实施自己的速率限制，这将阻止您的应用程序达到第三方API的限制。

为了做出更明智的决定，最好监视第三方API的使用。 使用Bearer （我工作的公司）之类的工具，您甚至可以设置规则以在使用量达到特定点时通知您，并以编程方式对其做出反应 。

考虑到所有这些，您的应用程序应该对“太多请求”错误更具弹性。

From: https://hackernoon.com/error-429-too-many-requests-what-to-do-when-youve-been-rate-limited-265e32tb