- From: David Booth <david@dbooth.org>
- Date: Thu, 31 Jul 2014 16:41:12 -0400
- To: Ruben Verborgh <ruben.verborgh@ugent.be>, Erik Wilde <dret@berkeley.edu>
- CC: Andreas Kuckartz <a.kuckartz@ping.de>, "public-hydra@w3.org" <public-hydra@w3.org>
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. David Booth
Received on Thursday, 31 July 2014 20:41:41 UTC