Re: 404 Re: Comments on the Triple Patterns Fragments draft

A little more explanation . . .

On 07/31/2014 04:41 PM, David Booth wrote:
> Hi Ruben,
>
> On 07/30/2014 09:19 AM, Ruben Verborgh wrote:
>> Hi Erik,
>>
>>> client: "give me the set of things matching this pattern." server:
>>> "here is the set you asked for. it happens to be empty."
>>
>> Yes, that's indeed the other possible interpretation.
>>
>>> if you want to provide a special service for checking for empty
>>> versus non-empty results, make it a proper service (i.e., give it
>>> an identifier)
>>
>> So you suggest another resource, which would indicate emptiness? I
>> understand, but I think we'd both agree this would be overkill for
>> the situation at hand.
>>
>>> instead of hacking status codes.
>>
>> Well… hacking… :-) My interpretation was just that "empty fragment ==
>> what you asked for doesn't exist on this server".
>
> I think that interpretation of 404 is a bit too loose.  The HTTP 4xx
> response codes are "Client Error" codes -- they mean that the client
> **seems to have erred**:
> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-6.5
>
> I do not think there is anything malformed about a query that returns
> 0 results instead of 5 results or some other number.  If such a query is
> treated as an error, then the client code must either: (a) special-case
> the 404 result; or (b) keep track of what data the server has, to avoid
> issuing a query that would return 0 triples, thus duplicating the
> server's job.  I would prefer to avoid that additional client complication.

I should add that requiring the client to special case the 404 result 
may be particularly unpleasant for the client programmer, because it 
breaks separation levels: it forces an error code to be reinterpreted as 
a legitimate data result, so the code cannot cleanly process error codes 
separately from legitimate data results.  It is qualitatively different 
from, for example, deciding at the business logic level to process 1 
result differently than 5 results.

David

>
> David Booth
>
>
>
>

Received on Thursday, 31 July 2014 20:56:28 UTC