Mailing-List: contact dev-help@clerezza.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@clerezza.apache.org
Received-SPF: error (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <51E70AF0.7080504@apache.org>
References: 
 <CALvhUEVkTmaV+3QA-H7fSHpjkP2fE6=16gZd-aotxnHVor7r-g@mail.gmail.com>
	<CAOzb7FKnw0hZdJvxWYNUhJtev5Bf8qs6mj+Xcam0i6GSBdNp0w@mail.gmail.com>
	<CALvhUEVtYJt_PHxwU0zD7oJNE_c7+qs-hTt+JJAuYmiB9i5DMA@mail.gmail.com>
	<51E70AF0.7080504@apache.org>
Date: Thu, 18 Jul 2013 18:18:30 +0200
Message-ID: 
 <CALvhUEVBgCroJ97qQoK0bkUpUb=44Pn9gokPZvo5AT_w_XHtnQ@mail.gmail.com>
Subject: Re: Sparql: handle queries and update requests together or
 separately?
From: =?ISO-8859-1?Q?Reto_Bachmann=2DGm=FCr?= <reto@wymiwyg.com>
To: dev@clerezza.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 17, 2013 at 11:21 PM, Andy Seaborne <andy@apache.org> wrote:
> On 17/07/13 10:08, Reto Bachmann-Gm=FCr 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 t=
hat
> SPARQL protocol defines.  The required difference is either MIME type or =
via
> ?request=3D or ?query=3D.  It's a very light check of the query string ne=
eded
> 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 leve=
l
> of HTTP - it does make it possible and it encourages different service
> endpoints for query and update which are different languages (for securit=
y
> 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 "re=
al"
> world because URLs over 1k (and more often 4k) are not reliable (some cac=
he
> 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 =3D=3D GET) || (paramName =3D=3D "req") || (contenType =3D=
=3D
"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 endpoi=
nt

If ((httpMethod =3D=3D GET) || (paramName =3D=3D "req") || (contenType =3D=
=3D
"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 th=
e
>>> 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
>>>>
>