It would be VERY helpful if we could pass in an array of show ids to request an array of shows.

Ideally you would download the full database dump and import it into your own database hosted somewhere so that you'd be able to get exactly the information you require, then periodically update it.

Second this, in situations where downloading the entire db is not practical, eg mobile apps, this would be very useful. It would also reduce the risk of hitting the rate limit.

This won't happen.

If you want to avoid unnecessary API requests, you can use the updates endpoint to determine if a show has been updated on our side since your last request.

david wrote:
This won't happen.
If you want to avoid unnecessary API requests, you can use the updates endpoint to determine if a show has been updated on our side since your last request.

They're meaning that even if you know what's been updated, if you need to get information for 5 shows you'd have to make 5 separate requests instead of 1 request specifying all 5 IDs

Sure, but what's the problem with issuing 5 separate requests? Just make sure that your client uses HTTP2 and the 5 small requests will be just as fast as 1 large request.

I see the point wich is near what I was mentioning here : http://www.tvmaze.com/threads/2256/request-what-has-been-updated

The speed is not really an issue. It's super fast :) for now. But by making a lot of calls, the rate limit can easily be reached. And the more it is used, the more it could blow up.

My own app warned me earlier that 22 shows I follow were updated in the last 24 hours. If I update them all on a single click, that'll be 22 calls in probably 2 seconds.

The ability to append multiple shows in a request (although sure easier said than done) would dramatically reduce that.

My 0.02c.

Don't forget this snippet in the API documentation: We say at least, because rate limiting takes place on the backend but not on the edge cache. So if your client is only requesting common/popular endpoints like shows or episodes (as opposed to more unique endpoints like searches or embedding), you're likely to never hit the limit.

Also, try to be smart about your client's architecture. If your app doesn't have a local cache but queries our API in real time, the rate limit is quite generous. The user would have to browse insanely fast to exceed it. If your app does have a local cache, why would all of the cached entries have to be updated simultaneously? You could just run the sync in a background task, iterate over all the entries that have to be updated and sleep for a few seconds as soon as our API gives you a HTTP 429.

I have a local cache and don't call directly the info for normal usage, only for updates. But a lot of shows get updated everyday.

Background sync is a possibility but may be luxury some apps don't have.

I'm nitpicking of course. I know the rate is high enough for individual links. Just that by principal, I'd rather make less but effective calls than making 20 calls just because a cast member had a birthday added on a lot of shows.

Anyway... back to bingewatch some missed episodes. ;)

It's also worth remembering that if API calls are being done directly from a smartphone application (and not a hosted website server) then they'll all have separate IP addresses and so the rate limit would effectively be per user.