Hello,
My main use case for the TMDB API is, for example, given a file
name like "BadBoys.iso", I want to find the right TMDB ID so I can
fetch (primarily) the overview text and cover/backdrop art and
display it in my HTPC application. I think this is probably a
pretty common use case.
So I turn this filename heuristically into "Bad Boys" and submit
it to the v3 movie search API.
At time of writing this returns six results and the first result
is the correct one. This works most of the time so I can simply
pick the first result.
Now, for the sake of argument let's assume I was actually
searching for some other movie with the same title.
My strategy was going to be to display the results of the search
in a list, then pick the right one from that list. The information
that I have to pick the right one is one or more of:
backdrop_path
id
original_title
popularity
poster_path
release_date
title
Ideally I would have liked the movie overview text in the
initial search response, but since it's not I thought I would
display (again in a list) the poster and backdrop with the title
and release year for each result. For the vast majority of cases
this too would probably be enough to identify the right movie
(assuming a poster and/or backdrop was available).
But then I found a problem with that, in that it looked like I
was getting an "adult" movie back in that list, and I do not want
to pull back any adult poster or backdrop art.
So what this leaves me with really, since I have no overview nor
adult flag, is to identify the right movie I now maybe need to pull
the movie info, director and/or cast list for each movie in the
search results - meaning at least (1+n) queries to TMDB, maybe
(1+2n) queries and so on.
Do you have any view on this? When you were designing the API
did you envisage some other usage pattern that I should adopt? Do
any other forum members have a better strategy for this? I am very
keen to minimise the number of queries I send to TMDB (and I do
cache everything locally once it's read the first time).
Thanks!