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
	with data payload
	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 (which unclear side
effects on state)) 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 among us is that a query does
_NOT_ change state (but see below about 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
- and given the profileraton of viruses, connect: spam - only getting
shorter over time.

Finally option 'C' sidesteps a lot of these issues - but is not cacheble
at all.  It is crystal clear though and has no side effects. 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 15:48:14 UTC