【问题标题】:Spotify Web API rate limitsSpotify Web API 速率限制
【发布时间】:2015-08-13 09:53:00
【问题描述】:

Spotify Web API 文档提到了速率限制。例如,authorization guide 是这样说的:

只能访问不访问用户信息的端点。 它的优点是应用了更高的速率限制。 在没有访问令牌的情况下向 Web API 发出的请求。

作为开发人员,我需要担心速率限制吗?如果我超过我的速率限制,对 Web API 的请求会失败吗?如果是,失败会是什么样子?

提前致谢。

【问题讨论】:

  • 这确实是你应该在文档中找到的东西,或者只是尝试一下。

标签: spotify


【解决方案1】:

您可以在User Guide 中找到有关速率限制的一些一般信息。如Status codes 中所述,如果您的应用程序发出的请求数超过允许的速率限制,Web API 将返回HTTP status code 429 (Too Many Requests)

如果发生这种情况,您应该等待一段时间(请参阅下面的更新),然后再再次发出请求。当然,最好的办法是一开始就尽量避免达到速率限制。正如用户指南所建议的那样,您可以通过例如一次访问多个可用于某些端点的实体来做到这一点。您还可以缓存响应。

更新:如果您受到速率限制,HTTP 响应将包含一个名为“Retry-After”的标头。此标头的值是您在发出下一个请求之前需要等待的秒数。例如,Retry-After: 4 表示您需要等待 4 秒钟才能重试。现在Web API User Guide也提到了这一点。

【讨论】:

  • 我认为情况并非如此。当我太快地发出太多请求时,通常会收到 500 错误...
  • 不应该是这种情况,可能是错误的迹象。知道您正在调用哪些端点会很有趣。我们在播放列表相关端点中确实存在一个已知问题。
  • Retry-After 值似乎是从毫秒计算的,四舍五入到最接近的秒。例如,如果 Spotify 打算取消 3200MS 的速率限制,您会收到 3 的 Retry-After 标头。在 3 秒后再次运行您的请求将意味着您的代码可能会违反 200MS 的差异。因此,您应该始终为 Retry-After 值 +1。
  • @MichaelThelin 有大约多少个数字吗?每分钟有 n 个请求
  • 之所以不公开是因为这个数字可能会在没有警告的情况下发生变化。使用 Retry-After 应该 足以编写一个处理速率受限的应用程序。也就是说,指望每秒大约 10 到 20 个请求会让您处于正确的位置。
猜你喜欢
  • 2021-07-24
  • 2020-11-04
  • 1970-01-01
  • 2014-08-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-03-24
相关资源
最近更新 更多