Oh, sorry, I thought it was specifically mentioned in there.
It could be that we'll add support for this in the future, but it's unsure yet. For now we recommend the method described in that thread.
david wrote:
Oh, sorry, I thought it was specifically mentioned in there.
It could be that we'll add support for this in the future, but it's unsure yet. For now we recommend the method described in that thread.
The problem with the solution in that thread is that it requires first being able to programmatically determine whether a single search isn't going to produce the desired result, and so a full search should be attempted instead. If the app logic is built around the single search API, it isn't such a trivial matter to move between it and full searches. Embedding currently works differently between them, for example, so a full search can lead to multiple queries to get the same info as from single search.
So if single search doesn't work in all use cases, some might conclude that it may be better to build the app logic around full search + multiple queries instead and take the hit. But then why have a single search API at all?
In my view, the single search API should provide the means to return any one of the results from the full search list, given enough query parameters to narrow down the list to just one result. That would be a reasonable yardstick for measuring its utility, I think.
Maybe I slightly regret creating the singlesearch endpoint as it is now ;)
The singlesearch endpoint was only created for usecases that really can't work any other way; like a chatbot replying to "/tv" commands. For serious matching, the regular search endpoint should be used. I always stated that very explicitly, and the API documentation even mentions it: Beware that if multiple shows exist with an identical name (for example, Top Gear) it's undefined which of them will be returned by this endpoint. If you want to be sure you're matching with the proper show, use the search endpoint instead.
And yet people using the singlesearch endpoint constantly expect a particular show to magically appear on top.
As I said earlier, I'm not completely opposed to adding filters like country or year to singlesearch or a similar endpoint in the future. But since you can already accomplish the same thing by using the API as it was intended, it doesn't have a huge priority. :)
David,
Thanks for continuing the conversation on this even though it's been asked about a million times :) I will say that I tend to agree with others that filtering logic makes a lot of sense to have on the single search api side, so that clients don't have to make many calls to the api in those cases. That being said I totally get where you're coming from and that there may be other pressing matters at the time. Anyhow, thanks again for all you do here!
Just to clarify: I think the distinction needs to be made between show matching functions and actual info returned by the search. While the full search obviously allows "proper matching", it doesn't return the info I need - or rather, it returns more than I need, and means I also need to make more requests against the show ID.
As for matching, I don't think people are expecting the single search API to "magically" return the result they want, but just be given the means to target programmatically the show they're actually looking for (and there are more use cases than "chat bots", but I think we already covered that point elsewhere). This seems quite reasonable to me, but I can understand if you have other priorities.
hecks wrote:
Just to clarify: I think the distinction needs to be made between show matching functions and actual info returned by the search.
Matching is what we've been talking about, I'm certainly not proposing that the actual info gets modified.
error result single search : jekyll & hyde
return : Hyde, Jekyll Me
jekyll & hyde exist in tvmaze
BrunoDusautoy wrote:
error result single search : jekyll & hyde
return : Hyde, Jekyll Me
jekyll & hyde exist in tvmaze
Already been noted here, and David says it will be fixed :)
david wrote:
That one should be fixed now.
Confirmed that it works on the site, but still getting weirdness with the API. When I use the show search endpoint and type "jekyll and hyde" it returns the expected results, but using "jekyll & hyde" with the ampersand hangs for a while and eventually returns the same results as before, with the 2007 "Jekyll" show as the highest score. Seems like maybe the ampersand is an issue afterall?
Are you sure you're properly URL-encoding the query string?
Ah, I was not. Thanks!