List of shows

Hmm, this isn't currently possible but it sounds like a plausible request. Let me think about it!

Hmm, this isn't currently possible but it sounds like a plausible request. Let me think about it!

Hi David,

Thank you, that will be great! Are you able to provide a current list of shows and id's in csv format? Even that will be useful if an endpoint is not possible. So maybe a csv file every 2 or 3 weeks? Depending on frequency of new shows added

Thank you for your help :)

If we add this it will definitely be a JSON endpoint, like all other API functionality. Just need to think about whether this is the right approach :)

If we add this it will definitely be a JSON endpoint, like all other API functionality. Just need to think about whether this is the right approach :)

Hi David,

Thank you for the feedback :)

If you do decide that it is not the right approach, I think I have figured another way I could get the shows (more work on my side :) )

By making use of this endpoint: http://api.tvmaze.com/shows/<showID> I can create a loop that will add the show names to a local DB. What I will need to know (via an endpoint) is how many shows are currently in the TvMaze DB?

Am I correct in guessing that there are 1788 shows currently?

What do you think?

Well, no, it doesn't sound like a great idea to have you make a separate request for each show in our database when all you want is the list of names. :)

We have to carefully consider such an endpoint though, as creating it could quickly escalate when the next person requests country information to be added as well, followed by premiere date information, etc. We'd quickly end up with way too much data for a single call, so perhaps there's a better alternative..

Hi David,

I don't mean to press the situation but it is an urgent request as far as UI is concerned for my app particularly for shows like The Flash where there is more than one. As providing a fast search suggestion popup is what my users need and the best approach is data referenced locally as the user types the letters of the show.

The csv dump I recommend to be the easiest right now with only two columns: ID and name. For the further requests you mentioned - country information, premier date - we will just reference the other endpoints for that information like we have always been doing without issue.

Please advise?

Regards

But if there is more than one show with the same name, how useful is it to only have the ID and the name available? Your autocompletion popup/dropdown would display two entries named "The Flash", and the user would have no clue which of the two is the one he's looking for.

To properly distinguish between multiple entries, wouldn't you need (almost) all of the information from the search endpoint?

But if there is more than one show with the same name, how useful is it to only have the ID and the name available? Your autocompletion popup/dropdown would display two entries named "The Flash", and the user would have no clue which of the two is the one he's looking for.
To properly distinguish between multiple entries, wouldn't you need (almost) all of the information from the search endpoint?

Hi David,

Thank you for the swift response.

Take the IMDB's search suggestions for example which include poster thumbnail images as well in addition to the show name. They also add the top two cast members so you know which exact show you are searching for. So in my case as you are typing "The Fl.." the results come up with two possible choices for the user - each unique (behind the scenes) by the show's ID (528 and 13) in the TvMaze database. The user clicks on 669 (which is the most likely choice in 2015) and the endpoint http://api.tvmaze.com/shows/13 is invoked thus taking the user to their exact result.

Another case in point is the many CSI's in production - the full list of possible CSI's - Miami, NY, etc would be displayed to the user to make it easier to search.

Hope this makes sense?

Yeah, I completely understand what you mean, but doesn't your example support my opinion that merely an id+name isn't very useful as source for search suggestions? (And that you would need additional information as well, such as poster thumbnail images, cast members, etc, etc)

Let me rephrase it: if you only had a list of id+name to populate your search suggestions, how would the user ever know which of the two entries for The Flash is "the most likely choice in 2015"?

Hi David,

I get what you are saying and its also my efforts to try and minimize the amount of data you have to compile for us on a regular basis. This can be two-fold: either I deal with the poster retrieval app side (posters will have to be displayed in search), that is, by having the ID's listed in the user's search suggestion (528 - The Flash, 13 - The Flash), a query can be made for the poster path to get http://tvmazecdn.com/uploads/images/medium_portrait/0/148.jpg (this is always going to be a remote query to the TvMaze CDN as images are never stored app-side); or the csv dump includes one more column for the original/medium poster path?

But if your setup requires you to make API calls before you can display the search suggestions, then what is the point of having a local cache of name+id available?

If I understand it correctly your proposal is:

1) User types "The fla"
2) Lookup "The fla" in local cache, and see that ids 528 and 13 match
3) Make an API call for each match, e.g. to shows/528 and shows/13 to lookup the poster URLs

If so, you could just as well make one single request to http://api.tvmaze.com/search/shows?q=the%20flash and get everything you need in one single request instead of two?

But if your setup requires you to make API calls before you can display the search suggestions, then what is the point of having a local cache of name+id available?
If I understand it correctly your proposal is:
1) User types "The fla"
2) Lookup "The fla" in local cache, and see that ids 528 and 13 match
3) Make an API call for each match, e.g. to shows/528 and shows/13 to lookup the poster URLs
If so, you could just as well make one single request to http://api.tvmaze.com/search/shows?q=the%20flash and get everything you need in one single request instead of two?

Hi David,

Thank you again for the reply.

You are right. My issue is local vs remote search. Am definitely not for having to store the show names app-side as it means regular maintenance/updates owing to the fact that new shows are added very regularly. Suggested search however seems to work best when the data is local to the user's environment. The issue does lie with the poster images which because they do not exist locally, a remote query for them has to be done.

Search result suggestions are displayed in a list (i.e Adapter) and within this adapter you can make a background query for the poster image. If you notice with IMDB the posters are loaded last but the show names are displayed quickly.

OK, so I slightly lost track of the discussion :) Do we agree now that only an id+name isn't very useful in most cases, or not?

To clarify: I'm happy to accomodate this usecase. But since we can't take something back once it has been released in the API, it requires some careful thought.

Hi

I skimmed through this thread, and if I got the issue right perhaps this could help you.

Take a lesson from googles "imdb the flash" search, and also include year in the db. This way the autofill could display "The Flash (2014)" and "The Flash (1990)" with the most recent show first.

What you really need to store locally would then be id+name+year?

It just depends on your UI, no? Someone else might want to include network / country / poster / summary snippets / status / etc information in their search suggestions interface as well.

It just depends on your UI, no? Someone else might want to include network / country / poster / summary snippets / status / etc information in their search suggestions interface as well.

Hi David,

Id and name is perfect. Having the year will be a bonus. Thanks @turbopipp for the suggestion.

Sorry, I think you don't understand the reason why I'm not yet very happy about that idea. :)

I don't want to create a solution that works for your specific usecase, but that doesn't work for other people's very similar usecases. If we'd do that for every request, we would eventually end up with a dozen of similar but slightly different endpoints that all have to be maintained indefinitely.

So for every request, I try to see the bigger picture and try to find a way that's as univeral yet flexible as possible, so that the implementation can be used as broadly as possible.

Sorry, I think you don't understand the reason why I'm not yet very happy about that idea. :)
I don't want to create a solution that works for your specific usecase, but that doesn't work for other people's very similar usecases. If we'd do that for every request, we would eventually end up with a dozen of similar but slightly different endpoints that all have to be maintained indefinitely.
So for every request, I try to see the bigger picture and try to find a way that's as univeral yet flexible as possible, so that the implementation can be used as broadly as possible.

Hi David,

I understand completely. Thanks for the feedback :)

I'm thinking in the direction of an endpoint that will list (with full information, like here: http://api.tvmaze.com/shows/1) all shows in our database, with pagination.

Since basic information like a show's name is unlikely to ever change, for most purposes - like yours - only your initial scan would have to check all available pages. Subsequent scans could simply start at the page number where they last left off.