I m playing with this recently found API and have a question on the search capabilities. If search for an entry like "Mad Dogs" the response I receive contains seven items. Two are exact matches by name but five are not. Is there a way to qualify the search so as to only receive responses for which there is an exact match ?
There isn't, but you can of course just compare your search term with the results on your end and filter out the non-exact matches.
Believe me I figured that out all by myself. I am developing some code to populate a local database with data for a few hundred TV shows, so I'm looking for any thing to simplify my life. It is a simple enhancement on your side, hence the request.
Our API design is optimized for maximum cacheability (in order to conserve resources), so it's unlikely that we'd implement a separate option/endpoint for something that can easily be done on the client-side instead.
A couple of observations
The order of items presented on this forum appears to be reverse date oder, which is to be expected. However my item is not shown, any reason why ?
Your response stating that an additional end point would need to be defined and maintained is I would suggest a bit of an exaggeration. I would suggest the same end point with a parm giving ?q=Archer?t=fuzzy/exact would suffice.
By the way when I do a search for a TV show named "Archer" I am presented with a response message containig 10 entries, with the following show names:
Name: Archer
Name: Archer
Name: Cabela's American Archer
Name: Arthur
Name: Watcher
Name: Parched
Name: The Watcher
Name: FarmHer
Name: Love Catcher
Name: Achar!
I am well familiar with the concept of fuzzy searching, but I hope you would agree that these results are rather extreme.in their fuzziness.
@MikeBrice wrote:
A couple of observationsThe order of items presented on this forum appears to be reverse date oder, which is to be expected. However my item is not shown, any reason why ?
Not sure what you mean here?
Your response stating that an additional end point would need to be defined and maintained is I would suggest a bit of an exaggeration. I would suggest the same end point with a parm giving ?q=Archer?t=fuzzy/exact would suffice.
A parameter like "t=" is what I meant by option :) Offering such a parameter would mean we'd have to process twice as many search operations, while search is pretty resource intensive. I understand that details like this aren't always functionally ideal, but it's the tradeoffs we have to make in order to serve an enormous amount of API requests both for free and with a high performance.
