ACTION-56: RESTful HTTP protocol Updates

All,


I took an action to summarize the options that are on the table for RESTful HTTP protocol updates,
http://www.w3.org/2009/sparql/track/actions/56
and this email is in response to that action.

I have found it convenient to divide into four options, and I propose to a strawman poll on each, whether you think it should be 
required, time-permitting, don't care or don't want. 

These are the four options:

I. Simple HTTP verbs only

I believe this is the simplest case, just the familiar HTTP verbs to manipulate graphs where you are priviliged to act on the graph name URI. In this proposal, we can take the following as a starting point, taking {graph-uri} as a meta-syntactic variable denoting the URI of the graph.

POST {graph-uri}
will insert the triples in the message into the {graph-uri} if it does not exist, if it exists it will add the triples of the message to the graph

PUT {graph-uri}
will insert the triples in the message into the {graph-uri} if it does not exist, and replace the graph if it does.

DELETE {graph-uri}
will drop the graph identified by the {graph-uri}.

GET {graph-uri}
will return all triples of the graph.

II. Add a graph parameter

I tried to draw the line on when this is needed in 
http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0059.html
The short story is that when the client can't be authorized to manipulate the {graph-uri}, one should be able to provide it to the endpoint to be able to manipulate the graph using the HTTP verbs above anyway.
This can be done by encoding it in the Request-URI or a header. 

III. Deal with round-trip concurrency issues

The IBM proposal, below, raises the question and proposes a solution to the problem that a client may GET a graph, and then another client modifies the content of the graph before first client has the chance to PUT or POST modified content back to the graph, possibly creating a mess.
We should decide if this a problem we want to address.

IV. Adopt the IBM proposal as starting point.

The IBM proposal,
http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/att-0040/SPARQL-UProtocol-20090707.html
addresses all of the above, although it is not very clear about II. It also introduces a HTTP PATCH verb (which is in HTTP 1.0, not 1.1) and a Graph HTTP header to allow more flexible naming of graphs. 
Thus, the fourth option is to adopt the IBM proposal as it is as a starting point for the WG. 

Best Regards,

Kjetil