Re: HTTP Protocol review

Chime,

Looks much better! I'm happy with pretty much all these changes. Just a couple of remaining issues, for which I think I just need more clarification. Details below.

On May 17, 2010, at 7:22 PM, Chimezie Ogbuji wrote:

>> --------
>> 5.3 POST
>> 
>> I can't make sense of this: "and distinguish such a request from the insertion
>> use case on the basis of whether or not the request URI identifies networked
>> RDF knowledge managed by the server".
> 
> That paragraph has been changed to "Alternatively, if the request URI
> identifies a container resource (designated by the origin server) and not
> networked RDF knowledge, the origin server SHOULD accept the RDF payload
> enclosed as a request for the container resource identified by the request
> or encoded URI to create a new RDF graph comprised of the statements in the
> payload. The server SHOULD return the URI associated with the new graph via
> the Location HTTP header in a 201 Created response. This scenario is useful
> for situations where the requesting agent either does not want to specify
> the graph IRI of a new graph to create (via the PUT method) or does not have
> the appropriate authorization to do so."
> 
> So, if the graph IRI (embedded or otherwise) corresponds to an existing
> graph, the triples are inserted into it, otherwise, this operation
> corresponds to the addition of graph by submitting to a service that assigns
> the graph IRI.

The equivalent Update syntax given for POST is:

CREATE GRAPH <graph_uri>
INSERT DATA { GRAPH <graph_uri> { .. RDF payload .. } }

The use of CREATE GRAPH here suggests that the POST operation will fail if the graph already exists. Is that right? If it doesn't exist, it's meant to be created on-the-fly, making this equivalent to PUT for non-existent graphs?

>> Is the "insertion use case" just the use
>> of POST on a previously-non-existant graph? Should the Location HTTP header be
>> returned with a 201 Created response even if the graph is indirectly
>> identified (and possibly not dereferencable)?
> 
> If the embedded IRI does not correspond to an existing graph then it either
> identifies a 'container resource' or it doesn't.  If it doesn't, the origin
> server should return a 404, otherwise the operation should proceed as
> defined.  I've added text clarifying this.

What is a "container resource"? Did I miss the definition somewhere, or is it defined in another spec? Is it just a graph IRI that already exists in the graph store? It seems to only be used in section 5.3, but I'm not actually sure what it is.

The text says a container resource is "designated by the origin server". How?


>> --------
>> 6. Conditional Requests
>> 
>> The text in this section talks about "any of the operations", but only goes on
>> to talk about GET requests. I'd like to see some discussion of how conditional
>> requests work with PUT, DELETE, and POST requests, and especially in
>> combination with indirect graph identification.
> 
> But the semantics of conditional requests apply to all operations in the
> same way that If-Modified-.. Etc. headers can be used with any HTTP Method
> and the interpretation of the request would follow from the HTTP rfc.  I
> don't think the management of RDF presents any caveats that should be called
> out.

OK, fair enough. It's just that RFC 2616 pretty much only talks about conditional GETs. I could go either way on this, but in general I prefer having more examples rather than fewer :)

thanks,
.greg

Received on Tuesday, 18 May 2010 00:28:39 UTC