- From: Rob Vesse <rav08r@ecs.soton.ac.uk>
- Date: Thu, 17 Jun 2010 14:26:09 +0100
- To: <public-rdf-dawg-comments@w3.org>
- Cc: <public-sparql-dev@w3.org>
- Message-ID: <EMEW3|62d5b872b8ce46be662af3669fd29980m5GEQF06rav08r|ecs.soton.ac.uk|730fce3857>
Hi Having looked over the document some more and started looking at how I would implement support for the protocol in my own library I have some further comments on the document. HTTP RESPONSES Currently the document is quite vague on what response codes should be sent for different results or what the server should do in the event of certain error conditions etc. which for a document defining a RESTful interface is unusual. I'd prefer the document to be much more specific particularly when it comes to response codes as this makes it much easier for developers of both servers and clients to create properly interoperable implementations. Some of the things I'm not sure what the response code/behaviour of the protocol should be are as follows. Where applicable I've put what response seems most appropriate to me in italics - since this part of the comment is subjective I've also CC'd this email to the SPARQL developers list: * Unsupported HTTP Verb used - _405 Method Not Allowed_ * Unable to resolve URI/invalid URI provided - _400 Bad Request_ * A GET operation is performed on a Graph that does not exist in the store - _Empty graph returned, should a 404 Not Found be returned?_ * Implementation does not support an operation e.g. DELETE on a read-only store - _405 Method Not Allowed_ * Implementation does not implement an operation - _501 Not Implemented_ * Implementation cannot return an RDF graph in any of the formats specified in Accept header - _406 Not Acceptable, alternatively could default to RDF/XML?_ * Implementation cannot understand the media type of the RDF payload - _415 Unsupported Media Type_ * Parsing of RDF payload fails - _400 Bad Request_ * A well defined error occurs while processing a request e.g. attempting a DELETE on a non-existent Graph - _400 Bad Request_ * Implementation encounters an error - _500 Internal Server Error_ BEHAVIOUR OF POST As it currently stands the behaviour of POST seems unclear to me due to the section about what happens in the case when the Graph URI provided identifies the store itself and the consequent minting of new Graph URIs to which the POSTed payload is then added with the newly minted URI being returned as a Location header. The document could do with a more concrete example of such a request (perhaps even examples of a HTTP request-response sequence) and clarifying this section. Currently I have not attempted to implement this part of the specification because I am not entirely sure what I should be doing. BEHAVIOUR OF GET The document does not appear to state what should the behaviour of a GET be in the event that there is no such Graph in the store? Should an empty graph be returned or should a server respond with a 404 Not Found? ADDING HEAD TO THE PROTOCOL Has the WG considered the possible use of the HEAD verb in the protocol for the determining of whether a given Graph exists in a store without retrieving it's entire contents? Possible use cases are things like: * Checking whether a Graph is already present before attempting a PUT esp when the Graph to be uploaded is large * Checking whether a common/required graph is already present e.g. copies of schemas/ontologies A HEAD request would be equivalent to doing an ASK WHERE {GRAPH { ?s ?p ?o } } Regards, Rob Vesse -- PhD Student IAM Group Bay 20, Room 4027, Building 32 Electronics & Computer Science University of Southampton
Received on Thursday, 17 June 2010 13:26:49 UTC