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

Comments on Graph Store HTTP Protocol (20110512)

From: Simon Johnston <simon@johnstonshome.org>
Date: Wed, 18 May 2011 08:46:42 -0700
Message-ID: <BANLkTikwNgAz3VCMtncaEh7zEEgJNCxM4w@mail.gmail.com>
To: public-rdf-dawg-comments@w3.org
Having read the latest draft I have a number of comments, though none I
believe substantial.

1. In section 5.1, in addition to the status codes listed I would add 415
where a clients issues a POST or PUT with a content type that is not
understood by the graph store. I would also include in this summary the use
of 403 and 406 which appear later in the text. The use of 401 and 403 can be
forward referenced to section 6.

2. In section 5.3, I would be more explicit on the use of "overridden"
perhaps with an example, does this mean a user can forbid a resource to be
deleted, or can see pending deletes and reject them, or later "undelete" a
deleted resource?

3. In section 5.4, the Location response header is mentioned in the case of
POSTing an "anonymous" resource, however it should be recommended that all
POST operations return a Location header allowing the service to use a
different base URI for POST that for GET/PUT/DELETE. This Location response
is optional where a URI is provided and required where it is not (as per the
current text).

4. In section 5.5, I would like to see the text refer to RFC2616 section 13
for details on recommended cache-control headers and usage.

5. In section 5.6, I would like to see the comments on caching as a distinct
paragraph with reference to RFC2616 for details (the parenthetical comment
is incomplete).

6. (Additional), I would also like to see the addition of comment on the
support for "conditional" methods, for example it should be a requirement
that ALL methods return the ETag or Last-Modified value of the current state
of the resource (with the possible exception of a DELETE method that returns
202 and has not yet completed the operation). PUT and DELETE SHOULD require
the use of conditional headers (If-Modified-Since, If-Unmodified-Since,
If-Match, If-None-Match, or If-Range) so as to provide concurrency control
on update. The GET and HEAD methods MAY use these values also to allow for
the return of 304 NOT MODIFIED.

Otherwise this is very clear and well organized.

Simon Johnston (simon@johnstonshome.org)
Received on Friday, 20 May 2011 06:56:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:11 UTC