- From: Kjetil Kjernsmo <kjetil@kjernsmo.net>
- Date: Fri, 1 Aug 2014 00:00:52 +0200
- To: public-hydra@w3.org
On Thursday 31. July 2014 22.55.59 David Booth wrote: > 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. I'm with Ruben here, I would certainly not be required to interprete the payload of the error separately. I don't know about other environments though. The whole difference is that with a 200, I would have to parse the payload to see if there was an empty result, with 404, I can safely conclude already once the HTTP response is parsed. For a SPARQL implementation on the top of LDF, that sounds like huge win to me: If a single triple pattern of a BGP returns a 404, I can stop processing that BGP and return an empty result for the whole BGP, while I would have to parse the result if it returned a 200 for every triple pattern. Cheers, Kjetil
Received on Thursday, 31 July 2014 22:01:31 UTC