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

hello ruben.

On 2014-07-30, 14:29 , Ruben Verborgh wrote:
> I'd argue that they are mostly thinking in an RPC-style.
> That is: client says "execute this query", server says "200, I did it".

i'd say the conversation is like this:

client: "give me the set of things matching this pattern."
server: "here is the set you asked for. it happens to be empty."

> However, I don't consider triple pattern fragments really as querying;
> I like to think of them more in a resource-oriented way:
> client: "do you have the resource 'things that are aliens'?”
> server: "404, don't have that one."

what you're asking for is a "result set" (or use any other term you like 
better if that one is to database-ish for you). what you get is the 
result, unless you're asking for a result set that the server cannot 
possibly give you, in which case a client error would be the proper 
status to use.

>> (and i think it's rather strange to think of such a query as "an error the client has to fix").
> "You asked for something I don't have, maybe somebody else has it.”

the server does have the result set, it just happens to be empty. if 
that's a special case for the client, just count the results, and invoke 
special logic for the "zero results" case.

> What about the aforementioned cases 2 and 3 if we go that way?
> 2) With "empty => 404", checking for a simple triple pattern
> requires simply a HEAD request, not a GET + body parsing.

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) instead of hacking status codes. then results can be cached 
and reused and interactions can use either one or the other service, 
depending on what clients want to do.

> 3) With "empty => 404", triple pattern fragments
>      can be implemented by a simple file server.

so you want to avoid any parsing of requests and simply map all requests 
1:1 to file names? i am curious how far you can take that, but that's a 
different question, i suppose.

> However, there are different ways to spec it though:
> a) server MUST return 404 if the fragment is empty
> b) server SHOULD return 404 if the fragment is empty
> c) server MAY return 404 if the fragment is empty
> d) server MUST NOT return 404 if the fragment is empty
> Which one would you recommend?

why does it need to be special-cased at all? if it's a valid query, then 
return the result (which happens to be empty). it should be no different 
than responding to any other valid query. if the query itself is 
erroneous, then yes, serve a client error.

> Case 2 only works with option a, unless we change b or c to:
> b'/c') server SHOULD/MAY return 404 if the fragment is empty,
>      but MUST do so consistently, i.e., it either returns 404
>      for all empty fragments, or returns 200 for all empty fragments.

that would be horrible because it would specifically allow 
non-interoperable implementations. also, since we're talking REST, 
there's no concept of a "server" anyway; clients should not need to and 
simply cannot know if two different URIs are the same or different 
"servers".

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Wednesday, 30 July 2014 12:55:21 UTC