W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > January 2011

Re: HTTP DELETE operation

From: Kjetil Kjernsmo <kjetil@kjernsmo.net>
Date: Fri, 14 Jan 2011 12:28:00 +0100
To: public-rdf-dawg-comments@w3.org
Message-Id: <201101141228.00677.kjetil@kjernsmo.net>

I'm catching up on the specs now, and I'd like to return to this:

Onsdag 20 oktober 2010 17:03, skrev Chimezie Ogbuji:
> > 1) If the <graph_uri> does not exist before the deletion, do I have to
> > return a 404?
> Yes.  The last paragraph of section 5 is meant to apply to all the
> operations regarding both 404 and 204:
> "If existing RDF knowledge is modified, either the 200 (OK) or 204 (No
> Content) response codes SHOULD be sent to indicate successful completion of
> the request [..] If the RDF knowledge identified in the request does not
> exist in the server, and the operation requires that it does, a 404 (Not
> Found) response code SHOULD be provided in the response."
> DELETE requests require the existence of the resource it is addressing, so
> a 404 needs to be returned.

I've seen in SPARQL Update, section 3.2.2., a store that do not record empty 
graphs will always return success. 

Also, in 3.1.3, it says "Deleting triples that are not present, or from a 
graph that is not present will have no effect and will result in success." 

It then strikes me as odd that the HTTP DELETE operation SHOULD return a 404, 
IMHO, it would be more natural, given the above and the overhead resulting 
from checking if a graph is present, to say that HTTP DELETE MAY result in a 
404 if a DROP would have resulted in a failure. One may not want to connect 
it that strongly to SPARQL Update, but the basic idea, that only a failure 
status in the underlying framework will result in a 404 I think is important.


Kjetil Kjernsmo
PhD Research Fellow, University of Oslo, Norway
Semantic Web / SPARQL Query Federation
kjetil@kjernsmo.net           http://www.kjetil.kjernsmo.net/
Received on Friday, 14 January 2011 11:29:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:28 UTC