Re: HTTP DELETE operation

On Wed, Jan 19, 2011 at 9:26 AM, Kjetil Kjernsmo <kjetil@kjernsmo.net>wrote:

> Fredag 14 januar 2011 16:52, skrev Gregg Reynolds:
> > To me, "Not found" does not mean failure.  It says the operation has
> > successfully determined that the resource is not found.
>
> That's true, there could be many failure situations other than not found.
> However, about DROP the Update spec says:
>
> "If the store records the existence of empty graphs, then the SPARQL 1.1
> Update service, by default, is expected to return failure if the specified
> named graph does not exist. ", which is the only failure situation it
> specifies, so that's what we have.
>

I think the language of the Update spec is a little broken.  The following
language is used in the sections on CLEAR and DROP

"If the store records the existence of empty graphs, then the SPARQL 1.1
Update service, by default, is expected to return *failure* if the specified
graph does not exist."

What does "the specified graph does not exist" mean, where the store allows
empty graphs?  It could mean the graph name is not found, or it is found,
but its graph is empty (or, it does not "point to a graph", or "has" no
graph.)

I think the success/failure language should be reconsidered; it doesn't
reflect the real semantics very well.  It would be better to talk in terms
of exceptions; then you get language that works both for programming
languages and for communications protocols, among other virtues.  Then
"GRAPH NOT FOUND Exception" represents an unusual but not entirely
unexpected condition, and it does not and need not reflect the success or
failure of an operation.  Use of "exception" would also remedy the problems
of the following clause from section
3<http://www.w3.org/TR/sparql11-update/#sec_updateLanguage>
:

" If multiple operations are present in a single request, then a result of *
failure* from any operation must abort the sequence of operations, causing
the subsequent operations to be ignored."
This clause provides the essential semantics of "failure", but to me it
doesn't make much sense.  What about preceding operations, do they have to
be rolled back?  And ignoring subsequent operations essentially means
shutting down the program, no?  The problem is that this language attempts
to define failure, where it should just describe exception conditions.
 Define failure in this way and you end up stipulating how software is
supposed to behave; but I don't think the spec should be telling
implementers how their exception handling should work.  Some exceptions are
recoverable, others are not; either way, the spec should stick to an
enumeration of exception conditions.

To put it another way:  the return code or result of one of these operations
should not be interpreted as a statement about the success or failure of an
operation, but about a state of the store.  The GRAPH NOT FOUND exception
tells us that it was not found and remains not found.  Instead of "success",
we would have the unexceptional GRAPH DELETED condition, meaning that GRAPH
FOUND was true before the operation, and GRAPH NOT FOUND is now true.
 Something like that.

Note the definition of 2xx from RFC2616: "This class of status code
indicates that the client's request was successfully received, understood,
and accepted."  This is as it should be; no mention of processing or
operations.



> My approach is pragmatic: I note that if I follow the current REST spec, I
> have to first do a ASK query to find out whether the graph exists. If this
> is
> really the intention, it should say so in the spec, since it lists which
> queries can be used.
>

That would not help, since you cannot make ASK then DELETE atomic.

>
> If you delete something, often you will simply not care if it was there or
> not
> before you did.


Which is why treating Not Found as failure, and defining failure to cause
aborting a sequence of ops, is a bad idea.


> My suggestion is therefore that the DELETE response should be tied to
> response
> of a DROP query of the Update spec.


All the specs should definitely be consistent on response semantics, but I
think the Update spec should be revised to use exception conditions instead
of success/failure.


> As long as the DROP returns only success
> or failure, I think that if it returns success, the HTTP response should be
> a
> 20x-code and the DROP failure means a 404, but an implementation MAY try to
> do further forensics to provide more detailed errors to the user, both in
> the
> case of of success and failure. I think that it SHOULD do such forensics
> beyond what's given by DROP is too strict and should be avoided.
>

I think you need at least two exception conditions.  One to mean a
processing failure; I'd suggest something like INTERNAL EXCEPTION (in this
case it really is the process that failed, but it could be any process); in
HTTP this would be a 5xx response. The other being something like NOT FOUND,
which could be either 404 (Not Found) or 410 (Gone).  Beyond that, the usual
HTTP response codes should apply; for example, if the resource is locked, a
GRAPH LOCKED exception might map to 409 (Conflict), etc.  The spec could
define a list of exception conditions without requiring that implementations
use all of them.

-Gregg