The Movie Database 支持

Hi everyone,

There's going to be some changes to the rate limiting we do on the API coming up shortly. This won't affect the rate limits themselves but rather how we calculate them and what we return. I'm happy to answer any specific questions should have one.

Let me first outline the key problems with our current system. Right now our API web servers are load balanced using Amazon's Elastic Load Balancer (ELB). When we first started doing this we only had 2 servers. With Nginx in front taking care of the rate limiting it worked ok for us. Keep in mind, Nginx doesn't share any kind of a hash table so each IP was technically, rate limited separately on each server. At 2 servers we were ok with this since the way we split traffic was generally by IP to each individual availability zone. This meant that mostly everyone's requests ended up at the same Nginx instance.

Fast forward to 2014 and our API web server cluster is 8 servers which is now making any attempt to rate limit with Nginx almost useless.

The new system will share the state of an IP address across all 8 instances and provide proper balanced rate limiting. The rate limits themselves remain unchanged (max. 30 requests in a 10 second span). The key difference is in the response handling during your requests and when you trip the rate limits. I'll give you some examples so you can make changes to your code before we go live with this change.

Every request will soon have these 3 headers:

X-RateLimit-Limit: 30
X-RateLimit-Remaining: 18
X-RateLimit-Reset: 1394060670
  • X-RateLimit-Limit: The number of requests you're allowed to make in a 10 second span.
  • X-RateLimit-Remaining: The number of requests you have left before the counter resets.
  • X-RateLimit-Reset: The Epoch timestamp when the counter will reset.

Right now when you actually trip the rate limits, we just throw a 503 error which is really not the right way to do this. Moving forward, we'll be throwing a proper 429 status code along with a Retry-After header telling you how many seconds to wait until you're allowed to make a request again. It looks like so:

HTTP/1.1 429
Content-Length: 104
Date: Wed, 05 Mar 2014 23:08:12 GMT
Retry-After: 7

Hopefully this will help you guys build better systems around the API. It's important for us to try and provide the best and most complete service we can and this should help a lot of you guys out.

Cheers.

20 回复(第 2 页,共 2 页)

Jump to last post

上一页

Hi @mani.db I don't know of any Python examples. I am not familiar with PHP but I know the PHP library is close to the most mature library around and it has built functionality to handle the rate limiting. Perhaps that will be of some help.

@travisbell , hi,

Does the rate-limit have any notion of 'in-flight' request? for example, what would be the behavior under the following scenario:

  1. The app starts-up and send 40 requests for the first time-frame
  2. The 10 seconds past, some of the requests returned some not, for example, I have 2 requests that did not return yet
  3. The app sends an additional 40 requests - now I have 42 requests in flight

Is this valid?

@mani.db said:

Hello, are there any example implementations in python (or other) to see how they respect this rate limit when issuing their requests?

Here's a quick and dirty example of how I implemented rate limiting for tmdb requests.

Hi, I was wondering if there is a paid option for the use of the API with much less restrictions around rate limiting.

Hi @rippedangelwings@gmail.com,

No, there is no paid option to upgrade rate limits at this time.

找不到电影或节目?登录并创建它吧。

全站通用

s 聚焦到搜索栏
p 打开个人资料菜单
esc 关闭打开的窗口
? 打开键盘快捷键窗口

在媒体页面

b 返回(或返回上级)
e 进入编辑页面

在电视季页面

(右箭头)下一季
(左箭头)前一季

在电视集页面

(右箭头)下一集
(左箭头)上一集

在所有图像页面

a 打开添加图片窗口

在所有编辑页面

t 打开翻译选择器
ctrl+ s 提交

在讨论页面

n 创建新讨论
w 切换关注状态
p 设为公开 / 私密讨论
c 关闭 / 开放讨论
a 打开活动页
r 回复讨论
l 跳转至最新回复
ctrl+ enter 发送信息
(右箭头)下一页
(左箭头)前一页

设置

想给这个条目评分或将其添加到片单中?

登录

还不是会员?

注册加入社区