clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <a...@apache.org>
Subject Re: Sparql: handle queries and update requests together or separately?
Date Wed, 17 Jul 2013 21:21:52 GMT
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
>>>


Mime
View raw message