clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür <r...@wymiwyg.com>
Subject Re: Sparql: handle queries and update requests together or separately?
Date Thu, 18 Jul 2013 16:18:30 GMT
On Wed, Jul 17, 2013 at 11:21 PM, Andy Seaborne <andy@apache.org> wrote:
> 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.

The question here is about Java methods not HTTP methods.

So the question is if we should have one method:

Object executeSparql(String)

Or two

Object executeSparqlQuery(String)
void executeSparqlUpdate(String)

(default graph params left out for simplicity)

The Sparql protocol requirements are a raeson for the second approach.
Even if we just have one HTTP enpoint the first approach would cause
more code an computation to be needed:

If ((httpMethod == GET) || (paramName == "req") || (contenType ==
"application/sparql-query")) {
    if (sparqlPreParser.parse(s).isQuery() {
        tcManager.executeSparql(s);
    } else {
        throw UpdateRequestSubmittedAsQuery();
    }
} else ...

Whereas with the secon approach no preparsing is needed for the http endpoint

If ((httpMethod == GET) || (paramName == "req") || (contenType ==
"application/sparql-query")) {
    tcManager.executeSparqlQuery(s);
} else ...

So the question for me is if there are other usecases which would
support having only a single method on the API level?

Cheers,
Reto


>
>
>         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