Re: How to express no matching results in HTTP SEARH method?

["Roy T. Fielding" <[e-mail]>]

> On Nov 5, 2020, at 11:37 AM, Mike Bishop <[e-mail]> wrote:
> 
> Roy, you seem to be disagreeing, but then presenting a detailed argument for
> the same position you're disagreeing with.  If the search was successfully
> performed on a resource, and the result of the search is an empty set,
> that's a successful operation (2XX).  If the search could not be performed
> for some reason, that's an error (4XX, 5XX).

That wasn't what I was responding to. The example given was a response
that was not a successful search: "SERVFAIL or NXDOMAIN" having a status
of 2xx. That's wrong.

> I'm confused.  Can you clarify why you don't believe that aligns with "if a
> search is successfully performed, then HTTP has succeeded"?

The general statement of "when a search is successfully performed we
would expect a 2xx response" is true to the extent that what the
application is actually doing is searching for something wherein
"none found" is a successful response, like most queries that
respond with a list of resources that match.

But SEARCH (the method) isn't limited to searching for something
according to some criteria. Maybe it should be. Maybe not. I don't
think it matters, so long as the protocol is self-descriptive and
doesn't respond success when the request actually failed by its
own semantics.

> (I disagree with you slightly about "find some among many," because the
> resource to be searched could be present but empty.  I think the
> differentiator is whether the targeted resource exists, regardless of what
> it contains.)

This isn't a helpful way to think. What we want from status codes
at the HTTP level is an indication of what recipients can do to
"fix this" even when they are not aware of the specific application
being processed over HTTP. A success doesn't need to be fixed.

For example, BigCo pays X megabucks to ensure that all valid queries
are processed within 50ms, including severe penalties when they don't.
The X has megaservers to respond to megaclients, but still doesn't
control probability and can't afford to buy a separate set of
megaservers for every specific application. So, it sprays all
SEARCH requests to N recipient servers in parallel and forwards
the first successful response. X cannot do that if it has to look
inside the body of a response to make an application-specific decision
about whether that response contains a successful SEARCH response.
Likewise, it might have an auditing requirement to store invalid
queries for some period of time, which it could do in 1 place
if the response indicates validity or in N places if it does not.

The easy thing for application developers to do is to always
send a 200 and make excuses within the content. If that was
generally considered to be an okay thing for one use of HTTP,
it would soon be for all uses of HTTP, and a whole bunch of
things that allow HTTP traffic to scale start failing.

....Roy