Re: update= vs query= (was: Re: http://www.w3.org/2009/sparql/track/actions/78)

On Wed, Sep 23, 2009 at 8:51 AM, Chimezie Ogbuji <ogbujic@ccf.org> wrote:
> Comments below inline.
>
> On 9/23/09 3:58 AM, "Lee Feigenbaum" <lee@thefigtrees.net> wrote:

<snip/>
>> The benefit to having update= is - I think - that it's easier for a
>> read-only endpoint to reject SPARQL/Update queries without needing to
>> parse the query.
>
> But it does so by parsing at least part of the URI, which I don't think is a
> good practice.  If only the SPARQL/Query interface was bound to to an HTTP
> 'service', then the server would simply not know how to handle a
> SPARQL/Update request

I'm not sure that I see the issue with this. If I'm accessing a URI on
a REST interface, then the majority of the URI is typically the same
as most other resources being accessed on that interface, and the
service code has to pull the URI apart to know if you have sufficient
privileges for the operation you're requesting. This occurs when
pulling apart the path or parameters (if the interface uses them,
which some do).

Another benefit to using query=/update= is that it tells the server
which parser to use, since the update language is different to the
query language. If we only use query= then my options (as I see them)
are:
- Have a single parser that handles both dialects. I then have to be
careful not to let updates through on GET requests.
- Have a query-only parser and a query+update parser (with lots of
redundancy between them). The query-only parser is used for GET and
the query+update is used for POST.
- Attempt to use the query parser, and fall back to the update parser
if it fails to parse.

I prefer the first mechanism, as I get more control. But it makes me
uncomfortable, as there is more potential for accidentally letting a
write operation through when the call should be read-only.

The proposal of query= or update= lets me choose the parser from the
outset, avoiding any questions of performing unexpected operations
from the outset.

Regards,
Paul

Received on Monday, 28 September 2009 15:27:50 UTC