Assistance de TMDB
Assistance → Assistance de l'API
Maximum Length of `append_to_response` parameter
posté par psubsee2002STAFFMOD le 16 février 2014 à 06h58
I found several discussions in which the feature to string together TV queries to get all of the season info and episode info for a single series using the append_to_response parameter.
/3/tv/1418?api_key=####&append_to_response=season/0,season/0/credits,season/0/external_ids,season/0/images,season/0/episode/1,season/0/episode/1/credits,season/0/episode/1/external_ids...
...,season/0/episode/1/images,season/0/episode/2,season/0/episode/2/credits,season/0/episode/2/external_ids,season/0/episode/2/images,season/0/episode/3,season/0/episode/3/credits,...
....season/0/episode/3/external_ids,season/0/episode/3/images
But I imagine this would get rather long if someone tried to get all of the season and episode information for a reasonably long series, especially if you want to include the external_ids, images, and credits/
Is there a maximum length for the append_to_response parameter? Or are we just limited to the maximum length that will be supported by the URL?
Réponse de Travis Bell
le 16 février 2014 à 10h10
Ya, there will be a max. There is actually a maximum length for GET requests itself. I believe Nginx limits it to 2096 bytes (characters).
It is definitely not designed to go and get every individual episode like that. Handy to be able to do a couple but the max that seems reasonable would be a single season's worth. The thing is, you're not using
append_to_responsethe way it was intended to be used.It is designed to be able to take a season and ask for all it's relevant details i.e.:
That way your "season" call is 1 request.
Same goes for episodes:
This all makes me think there probably should be a max. I don't mind people using it to get you know, maybe 20 extra objects but your scenario you're actually making 3 calls per season (instead of my example of one) and then 3 per episode (compared to again, 1 in my example). The way
append_to_responseworks is by simply making the calls in the background so executing a call with every method separate like this is actually a lot less efficient. (I know though, in your eyes you are making a single request but the way it builds the call in the background is different.)The only way to fix what I see in a call like this would be to support nested
append_to_responseparams but that is just getting crazy and is not something I'll support.I've created a new ticket for me to look at this, it's here. I'll tell you in advance, the max per call is going to be something like 20. So you can split up your calls appropriately.
Cheers!
Réponse de psubsee2002
le 16 février 2014 à 12h47
Thanks Travis. I actually never really planned to use it like this, the biggest I thought about was just stringing together the base
season/#calls to get a list of all of the episodes, which for nearly every series I can think of would be less than 20. I just wanted to make sure they was or wasn't a limit since you theoretically could string together than many requests. I'll make sure to limit my design to 20 or fewer additional calls.One additional question. Can you give me an idea how this would be handled server side if someone requests more than 20 (or whatever the limit ends up being? Would there be an error response of some kind or would it just return the first 20 extra objects?
And apologies in advance to anyone whose current program I broke because of this question.
Réponse de Travis Bell
le 16 février 2014 à 15h37
Great, thanks for asking.
We would end up throwing an error similar to an invalid api key error or invalid page error. You can see what that looks like by mashing in a random string for an API key or specify a page larger than 1000.
There's an open ticket to re-add the documentation for all of the valid error codes. It used to be online but was removed when 2.1 was taken offline. It will get re-added this week.