Re: update= vs query=

On 25 Sep 2009, at 12:33, Seaborne, Andy wrote:

[snip]

> I prefer query= and update= to keep them apart.  I use the servlet  
> API and the query string has been parsed to separate out the named  
> arguments so this is convenient in telling them apart before needing  
> to look at the body and invoke the right entry point in the parser.
>
> It will also help with ensuring updates are issued only over POST.   
> I can see some value in a common name for a simple client to pass on  
> strings without interpretation so if there were a "either=" (not  
> that name!) as well but it lets in update requests being sent over  
> GET.  Binding "update=" to POST only makes it clear.  And isn't it a  
> regex to tell 99% of the cases apart so that isn't a burden for the  
> client to do it.

I have a concern with what happens when you receive a POST request  
using "either", e.g.

SELECT { ?x ?y ?z }
INTO <http://foo.example/somegraph>
WHERE { GRAPH <http://bar.example/somegraph> { ?x ?y ?z } }

If would be very hard for the endpoint to make a sensible guess as to  
whether it should try an interpret this as SPARQL/Query or SPARQL/ 
Update, and would have trouble returning a sensible error message in  
either case.

Additionally, I like the separation that query= and update= gives,  
potentially avoiding some of the problems that SQL has from (often)  
sharing a common API for pure query operations and update operations,  
if the SPARQL client has to be explicit.

If there's some application where the client really want to have a  
single method then it can do the regex client side to make the guess.  
At least then it can inform the application which it attempted to  
treat the query as, which would help with debugging.

- Steve

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD

Received on Saturday, 26 September 2009 09:09:13 UTC