W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > January 2005

SPARQL Protocol for RDF / feedback (fwd)

From: Dirk-Willem van Gulik <dirkx@webweaving.org>
Date: Thu, 20 Jan 2005 01:55:54 -0800 (PST)
To: public-rdf-dawg-comments@w3.org
Message-ID: <20050120015542.Q39408@skutsje.san.webweaving.org>

Some feedback

URI layout

a	GET http://foo.com//qps?query-lang=http...&graph-id=http..my.example%2F3.rdf&query=...
b	GET http://foo.com//qps/query-lang=http.../graph-id=http..my.example%2F3.rdf/query=...
c	POST http://foo.com//qps

Though A and B are a URI with equal status and semantics - in reality
caches, loadbalancers, proxies and what not threat A as a function with
some argument (and implicitly assume some operation) and B in a more
stateless way. And hence will not be eager to cache around a - and be
sticky by default in the case of a load balancer.

This means that -if- the social contract is that a query does _NOT_ change
state (but see below abotu GraphCreated) - and that thus the results can
be cached or can be handled loadbalancer neutral that 'b' gives a
behaviour closer to that desire.

Secondly a fair number of security product(concerned with things like
cross site scripting, buffer overuns, viruses, etc) inspect the part after
the ? different than before.

Given that the queries can be long-ish - and will not match the easy
patterns of 'total=51&name=Fred+Blogs' this is somewhat a concern.
Secondly size limits imposed are different for the path and query element.

Finally option 'C' sidesteps a lot of these issues - but is not cacheble
at all. However it is much more appropriate when things like a
GraphCreated' and a 'OperationRequestAccepted' are going to be
implemented. However with 'C' and 'A' the desired semantics of things like
PermanentlyMoved and TemporarilyMoved would need to be made very clear as
a lot of software assumes them to apply to the fqdn/path part of the URI
and -not- to the ?= query part.

Received on Thursday, 20 January 2005 09:59:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:05 UTC