RE: update= vs query=



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> request@w3.org] On Behalf Of Steve Harris
> Sent: 24 September 2009 10:50
> To: public-rdf-dawg@w3.org Group
> Subject: Re: update= vs query=
> 
> On 23 Sep 2009, at 19:09, Lee Feigenbaum wrote:
> 
> > Chimezie, I think I understand what you're saying, but wanted to ask
> > you whether defining update in the /Protocol document as its own
> > interface (so it can be found to its own URI endpoint) but _also_
> > defining the update operation to have an update= (rather then
> > query=) parameter would satisfy your HTTP sensibilities.
> >
> > This would (I think) mean that admins who wanted to could deploy on
> > separate URIs and maintain the "URI drives operation" setup that
> > your'e advocating, while other admins could have a single endpoint
> > which dispatches to a SPARQL/Query or SPARQL/Update processor based
> > on whether query= or update= is sent up.
> 
> That's certainly my preferred solution.
> 
> - Steve
>

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. 

 Andy

Received on Friday, 25 September 2009 11:34:18 UTC