Happy to see my issue with this is being taken seriously :-), I will be updating php-tmdb-api soon to support it. For any other authors / interested folks, this is the relevant ticket: http://tmdb.lighthouseapp.com/projects/83077/tickets/356-implement-rfc6585-section-4-for-rate-limiting .

Are the servers solid state based now?

I found a huge performance increase in our API transactions by mysql and the OS to them. No more need for rate limiting :D

Are the servers solid state based now?

Our DB and web servers are, yes. The SSD's have close to no effect on the web servers though as everything is served from memory. We do very, very little IO. The bigger difference we noticed was just bumping to the new c3 instances with their better CPU's.

No more need for rate limiting :D

This has no bearing on us choosing to rate limit. We have had a lot of trouble with people pushing code into the wild that ends up stuck in loops forever and ever (we had one client in particular that was generating over 6,000 requests per second all by itself, looping forever and ever until we got the developer to push a fix for it). When you process the kind of requests we do it just becomes a natural requirement—we can't let a few bad developers ruin the experience for everyone.

Has this been implemented yet? I'm not seeing the headers (or the rate-limiting) on the production api.themoviedb.org

-Mike

Hey Mike,

No not yet, I'm waiting on our ops team to deploy this.

Oh cool. Will check in later then :)

At this point, are the limits being enforced?

I created a test script, but that didn't gave me any warnings:

require 'themoviedb'

Tmdb::Api.key("xx")
times_counter = 0 
100.times do
  Tmdb::Movie.find("batman")
  times_counter += 1
  puts times_counter
end

Hey guys,

We deployed this last night, and it is now live in production. We increased the rate limit to 40 requests every 10 seconds too, so there's a little bump.

Thanks Travis. I'll see to it that it gets supported in TMDbLib

This is a completely reasonable restriction in theory, but not on an API that is so frustratingly limited in methods for retrieving data.

I have a simple app that is basically an alternate view of a user's list. It pulls the list and then displays a table with title, runtime, poster, director, etc. This is what the API currently requires me to do:

1. GET /list/list_id
2. For each movie in list, GET /movies/movie_id
3. For each movie in list, GET /movies/movie_id/credits

For a list with 50 movies, this is 101 API calls just to get a couple kilobytes of data. With no way to get more than one movie at a time (by ID) and such a small selection of attributes returned for a list's movies, I'm already forced to mirror the data in a local database. Now when a user's list has more than a dozen movies I haven't mirrored yet, I hit the API limit.

What are my options here?

Hi dpmccabe,

I'm not sure of a potential feature/plan but you can trim your movie requests down to a single call with append_to_response. For each movie ID, you can call:

https://api.themoviedb.org/3/movie/{ID}?api_key={API_KEY}&append_to_response=credits

Lists is being re-written soon, so I can take that opportunity to think about this problem in more depth at that time.

Travis,

Perhaps a fetch method accepting multiple IDs?

Regards,

Travis,

I'm seeing 429 responses with the header: "Retry-After: 0".

This is counter-productive. Could you always set it to at least 1, or round up to the nearest integer?

also the error 429 occurs even when accessing after the time from X-RateLimit-Reset. Adding 1 second more helps but even then 429 happens sometimes...

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