Υποστήριξη για το The Movie Database
Υποστήριξη → Υποστήριξη API
Application design patterns considering rate Limiting and API Keys
Δημοσιεύτηκε από τον/την mathewtrivettSTAFFMOD στις 20 Ιούνιος 2017 στις 10:41 ΕΊΜΑΙ
Hello, I'm working on a side project that will use The MovieDB data.
Essentially I want for people to be able to extend data from TMDB, for example up vote and down vote and/or define custom genres / lists.
For the application to work users need to be able to pull down lists of films from TMDB and associated data from a custom database, so for example a request might be for all the films tagged with custom category 'Foo' on 'foofilms.com'.
If the API query came from the foofilms server then it would quickly hit API limits, particularly if it was popular. However passing a list of film ids to the client to query would require exposing the API to make a valid query.
What would be a sensible design pattern to resolve a project like this? Am I getting it wrong / overcomplicating things? Any advice appreciated.
Απάντηση από τον/την Travis Bell
στις 21 Ιούνιος 2017 στις 12:55 ΜΜ
Hi Mathew,
If you intend to bring data in house, your best bet is to cache the data locally and over time you'll hit the API less and less. You could do something like can preload the most popular 10,000 movies or something to that effect.
Lots of our users have their users hit the API directly, or, do a hybrid of both. It's up to you how you want to design it.
Απάντηση από τον/την mathewtrivett
στις 30 Ιούνιος 2017 στις 06:03 ΕΊΜΑΙ
Thanks for the reply Travis much appreciated. Its useful to understand different design patterns for application design that are respectful of the awesome service to offer.
One last question, I understand building image URLs will count towards rate limiting but do CDN hits count towards rate limiting too? For example serving movie images from built URLs?