Mailing-List: contact dev-help@clerezza.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@clerezza.apache.org
Received-SPF: pass (nike.apache.org: domain of andy.seaborne.apache@gmail.com
 designates 74.125.82.171 as permitted sender)
Message-ID: <51E70AF0.7080504@apache.org>
Date: Wed, 17 Jul 2013 22:21:52 +0100
From: Andy Seaborne <andy@apache.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: dev@clerezza.apache.org
Subject: Re: Sparql: handle queries and update requests together or
 separately?
References: 
 <CALvhUEVkTmaV+3QA-H7fSHpjkP2fE6=16gZd-aotxnHVor7r-g@mail.gmail.com>
 <CAOzb7FKnw0hZdJvxWYNUhJtev5Bf8qs6mj+Xcam0i6GSBdNp0w@mail.gmail.com>
 <CALvhUEVtYJt_PHxwU0zD7oJNE_c7+qs-hTt+JJAuYmiB9i5DMA@mail.gmail.com>
In-Reply-To: 
 <CALvhUEVtYJt_PHxwU0zD7oJNE_c7+qs-hTt+JJAuYmiB9i5DMA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 17/07/13 10:08, Reto Bachmann-Gm�r wrote:
> Hi Hasan
>
>>> The recent changes towards full sparql 1.1 treat queries and update
>>> requests together. That is we have one method that accepts both.
>>
>>
>> Do you mean HTTP method?
>
> I meant java method. But because it's the same Java method it will be
> harder for the code to handle queries via HTTP GET not also to allow
> update requests.
>>
>>
>>> I'm
>>> wondering if this makes sense. One reason against this approach is
>>> that the Sparql protocol mandates different ways for submitting
>>> queries and update requests.

Clerezza can have one API operation - it's the on-the-wire HTTP mapping 
that SPARQL protocol defines.  The required difference is either MIME 
type or via ?request= or ?query=.  It's a very light check of the query 
string needed but if you pre-parsing anyway, then you'll know if it's a 
query or an update.

In fact, SPARQL protocol does not mandate different endpoints at the 
level of HTTP - it does make it possible and it encourages different 
service endpoints for query and update which are different languages 
(for security reasons and for query/update injection attacks).  But it 
does not mandate any endpoint naming.

BTW
Queries can be sent by POST as well as GET - this is necessary in the 
"real" world because URLs over 1k (and more often 4k) are not reliable 
(some cache and proxy server silently truncate the URL).  And, from 
experience, I see people use POST on forms even when GET would do.


	Andy

>>
>>
>> If HTTP method is meant here, I can only find by quickly run through the
>> doc
>> http://www.w3.org/TR/2013/REC-sparql11-protocol-20130321/#protocol
>>
>> that we may want to use HTTP Get for the query and POST for the update.
>>
>>
>>> But if in clerezza queries end up being
>>> handled by a method than is also capable of updates it would be hard
>>> to enforce that no update comes in disguise of a query. (Not that this
>>> would be a security issue, but it would be against standard and best
>>> practices to update a graph on a get request).
>>>
>>
>> If that is the case, I think we can add or modify function in the preparser
>> to get
>> information about whether it is an update or query, and react accordingly.
>
> That would be one approach. The other would be two have two different
> methods in TcManager for queries and updates. And if we want a
> fastlane for updates too, to have two pre-parsers.
>
> Cheers,
> Reto
>
>>
>> Cheers
>> Hasan
>>
>>>
>>> Cheers,
>>> Reto
>>>