- From: Simon Johnston <simon@johnstonshome.org>
- Date: Thu, 19 May 2011 12:36:27 -0700
- 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. Thanks. -- Simon Johnston (simon@johnstonshome.org)
Received on Friday, 20 May 2011 06:56:58 UTC