[Mulgara-general] CRUD Operations in Java

Paul Gearon gearon at ieee.org
Sat Jul 18 03:23:16 UTC 2009


On Fri, Jul 17, 2009 at 9:13 AM, Alex Hall<alexhall at revelytix.com> wrote:
> David Legg wrote:
>> Alex Hall wrote:
>>> All of these operations (load, delete, and drop) are supported by the
>>> new REST interface to Mulgara.  More information is available on the
>>> wiki at [http://mulgara.org/trac/wiki/RESTInterface].
>>>
>>
>> Thanks for the link Alex.  I'm a little confused by what's stated on the
>> page though.
>>
>> It states a SPARQL interface is available at localhost:8080/sparql/ and
>> reminds us that SPARQL is query only.  Later it states a read only
>> interface is also available at localhost:8081/sparql/.
>>
>> The obvious question is if the 8080 port version can only do read only
>> what's the 8081 port for?
>
> That's a good question, and I had to look up the answer myself.  While
> the SPARQL *language* is read-only, you can also invoke CRUD operations
> on the SPARQL servlet interface running on port 8080 by using the REST
> operations.  In other words, the HTTP interface for SPARQL is a fully
> compliant implementation of the SPARQL protocol, but is overloaded with
> additional REST methods.  Those REST methods can be invoked by omitting
> the "query" parameter and using an HTTP POST, PUT, or DELETE as
> described on the wiki.  The public version disables the POST, PUT, and
> DELETE methods, restricting clients to use HTTP GET requests (with or
> without a "query" parameter) which by definition are read-only.

Thanks for pointing this out. I'll try yo update the documentation to
make this clearer.

> Note that there is no equivalent public read-only HTTP interface for
> TQL.  Even restricting the TQL interface to only handle HTTP GET would
> not be enough to guarantee read-only functionality, due to the fact that
> TQL commands may specify CRUD operations.  You would have to examine
> every incoming command to ensure that it doesn't try to modify the
> database, and I suppose Paul didn't think it was worth it. :-)

Actually, I did think it was worth it. If you try to do a TQL
modifying command with an HTTP GET then it will return an error.
That's because the HTTP RFC says that GET is not allowed to modify
anything in the server.

There were a couple of reasons I didn't create a read/only version of
the TQL interface:

1. SPARQL was defined as read-only and I wanted to have a mechanism
for enforcing that. Most applications need read-write operations,
which is why the SPARQL interface was extended (you'll find that most
other RDF stores have done this too).
2. TQL is not a standard, so there was no need to consider the
sensibilities of permissions at this level. TQL is also supposed to
allow for permissions at a deeper level, though this is currently not
enabled.
3. TQL has a lot of operations in it, with most of them modifying the
data store in some way. It didn't make much sense to me (at the time)
to have a pure read-only interface, particularly when SPARQL was going
to fill that need.

> Finally, let me point out that the REST methods on the SPARQL and TQL
> interfaces are a non-standard protocol extension.  There has been talk
> of adding support for graph modifications specified via REST methods to
> the next version of SPARQL, as discussed at
> [http://www.w3.org/TR/2009/WD-sparql-features-20090702/#protocol-update].
>  If you find these methods useful and would like to see them
> standardized, I would encourage you to speak up and make those wishes known.

This is definitely going to be standardized, though we're still
discussing what form it will take. Also, the SPARQL language will be
extended to enable updates as well.

The discussion for security on updates has come up, but the response
so far has been to allow it to be handled at the HTTP level. Just this
week we had the question of read-only endpoints vs read-write
endpoints, and a number of implementers said that they typically
provide a read-only endpoint on one part, and a read-write endpoint on
another port, just like Mulgara does. This seems to be the most
popular approach, as it allows for the greatest flexibility in access
and authorization.

Regards,
Paul Gearon



More information about the Mulgara-general mailing list