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

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".

> then results can be cached and reused and interactions can use either one or the other service, depending on what clients want to do.

Note that caching and reuse is as easy with the 404;
in fact, it's more effective because you don't need an extra resource for emptiness.
Two birds with one stone.

> 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.

It's pretty easy, really. Each triple is part of 2^3 = 8 files. Cheapest way of hosting queryable access.
Implemented in https://github.com/lmatteis/ldstatic.

>> 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?

- efficiency, because it's a common case
- ease of implementation (file server)

> 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.

Note that the request body is identical, regardless of status code.

> if the query itself is erroneous, then yes, serve a client error.

It still seems helpful to me to indicate already on the protocol level
"hi man, I don't have anything here for what you asked".

>> 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".

Agreed, that was a bad idea.


As the discussion is progressing, I have the feeling that "empty = MUST 404" is not sustainable.
Even though I see value in the server telling the client on the protocol level that there are no matches,
my interpretation of "no elements == doesn't exist" seems too much of a stretch.
It is great for efficiency though.

PROPOSED RESOLUTION
Remove all MUSTs about status codes,
add that the server SHOULD return 400 for invalid triple patterns.
We can then also drop the requirement for servers to respond to HEAD.

This would hugely simplify the spec and remove the strong dependency on HTTP,
which was the original issue Kjetil started this thread with.

Best,

Ruben

Received on Wednesday, 30 July 2014 13:20:13 UTC