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

[David Flanagan]

Warren Harris wrote:
> 
> On Jul 17, 2008, at 4:10 PM, David Flanagan wrote:
> 
>> It occurs to me that this is a case where it might be useful to return a
>> code /api/status/ok/empty.  It still indicates success, but allows it to
>> be special-cased, when desired.
> 
> -1
> 
> I realize that we may have told developers to look for a prefix matching 
> "/api/status/ok", but chances are they're not going to do this, and end 
> up with buggy code as a result.

Since this is a case where we're changing from an error code to a 
non-error code, any developer that tests using strict equality will just 
see an error in this case, which is what they were seeing already.  So 
it is not like this will break lots of existing code...

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 
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!

	David


> 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.
> 
> Warren
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Developers mailing list
> Developers at freebase.com
> http://lists.freebase.com/mailman/listinfo/developers