[Developers] minor change in search api behavior (empty result set will no longer be an error)

[Aseem Mohanty]

David Flanagan wrote:
> My point, I guess, is that if there is a worry, even in this case, that 
> too many developers already do strict equality tests rather than prefix 
> tests, then I can't imagine it will ever be acceptable to return an 
> extended ok code.  And we ought to just give up and document that it is 

My concern regarding changing the code is that it would pollute the 
meaning of /api/status/ok. I am not overly concerned about the 
strartswith vs strict equality check. The code has not changed in quite 
some time and barring some very compelling use cases that require 
otherwise I don't see it changing anytime soon.

I think it ought to be kept as simple as possible (which it is right 
now) and let clients have more intimate knowledge of the responses and 
their structure, rather than overload the 'ok' message space. This 
allows clients to be as smart or as dumb as possible.

> okay to do a strict equality test on the status code!  It would 
> certainly simplify everyone's error testing code to be able to use == 
> instead of indexOf or a regular expression match!

Perhaps its time to update the documentation to reflect the state of 
things as they are rather than what they might be :)

> 
>> The bottom line is that returning no results (empty list) is not an 
>> error. I'd even vote for striking the message from the result.

+1.

AM