SPARQL Protocol for RDF / feedback (fwd)

Some feedback

URI layout

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

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.

Dw.

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