Founded in 2006, TheTVDB is one of the longest-running community-driven TV and Movie databases. With content metadata across hundreds of thousands of TV series and movies, TheTVDB powers many of the largest media centers in the market. Developers across the world build and rely upon TheTVDB's APIs to power their apps, utilities, and projects, generating millions of API calls per day. In our GitHub repository you will find all of the necessary support and v4 API documentation to make use of TheTVDB's metadata. Come and join us!
140
stars
13
forks
source link
Inconsistent response structures for `/series/{id}/episodes/{season-type}` & `/series/{id}/episodes/{season-type}/{lang}` endpoints #346
Not really even sure where to begin with this. These endpoints are extremely similar in structure. Shouldn't the JSON responses that get returned somewhat resemble each other?
For example, consider the first endpoint (WITHOUT the language specification) with the following path -- I want to obtain the episodes for season 1 of the 'One Piece (1999)' anime (with the "official" season type)
/series/81797/episodes/official?page=0&season=1
In the JSON body root I have a data key whose object yields a dictionary with 2 keys - "series" (ROOT.data.series) & "episodes" (ROOT.data.episodes). This response seems to work just fine. I get all of the necessary episodes just for that season. Cool.
But if I want to specify a specific language (let's say English: eng)
/series/81797/episodes/official/eng
First of all, I can't even specify specific seasons or episodes (which is an unfortunate drawback). Additionally, now the schema's structure is different. Technically ROOT.data.episodes still exists but it's within the ROOT.data.series object from the previous endpoint. And that data now sits in ROOT.data instead of ROOT.data.series
Ultimately, I'd like to just see more consistency. Considering how long the API has been around, it's a little crazy all the hoops we have to jump through and all the separate requests we have to make to get translations for a show's data, its seasons, and its episodes.
Is there a plan to rectify this? I wasn't able to find another issue in the tracker that stated a similar problem.
I would have less of an issue with it all if we were able to specify a season and episode number like the first endpoint.
Not really even sure where to begin with this. These endpoints are extremely similar in structure. Shouldn't the JSON responses that get returned somewhat resemble each other?
For example, consider the first endpoint (WITHOUT the language specification) with the following path -- I want to obtain the episodes for season 1 of the 'One Piece (1999)' anime (with the "official" season type)
/series/81797/episodes/official?page=0&season=1In the JSON body root I have a
datakey whose object yields a dictionary with 2 keys -"series"(ROOT.data.series) &"episodes"(ROOT.data.episodes). This response seems to work just fine. I get all of the necessary episodes just for that season. Cool.But if I want to specify a specific language (let's say English:
eng)/series/81797/episodes/official/engFirst of all, I can't even specify specific seasons or episodes (which is an unfortunate drawback). Additionally, now the schema's structure is different. Technically
ROOT.data.episodesstill exists but it's within theROOT.data.seriesobject from the previous endpoint. And that data now sits inROOT.datainstead ofROOT.data.seriesUltimately, I'd like to just see more consistency. Considering how long the API has been around, it's a little crazy all the hoops we have to jump through and all the separate requests we have to make to get translations for a show's data, its seasons, and its episodes.
Is there a plan to rectify this? I wasn't able to find another issue in the tracker that stated a similar problem.
I would have less of an issue with it all if we were able to specify a season and episode number like the first endpoint.