@romanvm wrote: It makes perfect sense because it would allow to retrieve episode lists in different orders from a single endpoint and use the same code to process the retrieved information. For example, the TheTVDB API has a single endpoint for episode lists in different orders: https://app.swaggerhub.com/apis-docs/thetvdb/tvdb-api_v_4/4.2.8#/series/getSeriesEpisodes (they call order "season type"). The current implementation will require to write dedicated code to retrieve and process alternative lists.
Hmm, did you check the contents of the alternate episodes endpoint? The thing is that it's not exactly the same as for regular episodes, for example regular episodes have a URL and a main image while alternate episodes have not (but they do have a link to the underlying episode(s) that do).
@david wrote: Hmm, did you check the contents of the alternate episodes endpoint? The thing is that it's not exactly the same as for regular episodes, for example regular episodes have a URL and a main image while alternate episodes have not (but they do have a link to the underlying episode(s) that do).
I think that's exactly what they were saying; because the output isn't the exact same, it will need dedicated code.
Right, I thought @romanvm was just referring to the name of the endpoint, but I guess it's more likely that he means that the content should be identical to the regular episodes endpoint.
So the thing is that our system for alternate episodes is more advanced than just DVD re-ordering: it also allows for splitting and merging episodes. That also makes it impossible for the regular & alternate endpoints to be identical, because then some information would get lost in translation.
That said, I do understand your wishes for a simpler implementation that only supports the most common usecase. I could consider dropping the whole "alternateepisodes?type=dvd_release" redirecting endpoint and create something that has identical output to the regular episodes endpoint, but only works (properly) for that most basic scenario where episodes aren't split or merged.
It's simpler to parse, but it comes with the caveats that in case of split (2 alternate episodes pointing to the same underlying episode) lists, the alternate list will simply contain duplicated summaries and main images. And in case of merged (1 alternate episode pointing to 2 underlying episodes) lists, the alternate list will only return one of the available summaries and main images.
The structure is simpler but the enpoint is not consistent with what https://api.tvmaze.com/alternatelists/1 returns. It returns dvd_release: true, but the enpoint above says "dvdepisodes". So we need some mapping between JSON properties of /alternatelists/<id> endpoint and actual alternative order endpoints.
In any case, I have already implemented alternative lists support using https://api.tvmaze.com/alternatelists/1 and https://api.tvmaze.com/alternatelists/1/alternateepisodes?embed%5B%5D=episodes endpoints and currently testing it. For simple cases it works OK, but there are issues with language permiere order. I'd like to know if multiple language premiere orders may exist.
Currently we only allow for English language in alternate premieres (see https://www.tvmaze.com/faq/40/alternate-episodes) so there'll be a maximum of 1, but that limitation only exists in the policy, not in the backend. So in the future there could be multiple alternate lists with the type of "language_premiere".