Re: [ISSUE-32] Implications of updates on protocol, regarding HTTP methods

On Wed, Jul 29, 2009 at 2:05 PM, Paul Gearon<gearon@ieee.org> wrote:

>  queryHttpGet should be used in all
> cases, except where the query exceeds practical limits, in which case
> queryHttpPost is used, with the query provided in the body of the
> request.

I believe the word "length" is missing between the words "query" and
"exceeds" -- i.e., the spec says (or should have said; if "length" is
dropped in the original, that's an editorial bug) that you can
serialize a query string into the body of a POST in cases where the
query length is too long for a GET. No one did an exhaustive survey to
see what that length was when we were doing 1.0, so it was thought to
be careful and provide the POST fallback. (This may well be
practically mooted by modern HTTP server implementations; but it's
also unclear, or was at the time, what the practical upper bound on a
SPARQL query was going to be; one can imagine cases where it could be
nasty.)

A very very small point that I happened to notice.

> Option 4: Use appropriate methods for each action.
> This means using PUT to create resources, DELETE to remove them, GET
> and HEAD to query them. However, this is what the REST protocol will
> be doing, and makes the notion of a SPARQL/Update language
> superfluous.

This is what the first draft version of the 1.0 protocol defined; that
version did not achieve consensus and the simpler protocol with one
operation, query, did. Ancient history, to be sure, but there you go.
:>

> Option 2 appears to offer the least difficulty. Are other options available?

It's reasonable to expect that this option will have a high public
cost as it's a style of HTTP interface that is frowned upon by some
people. And in my experience their frowning can be quite costly to
process during Last Call, etc. FWIW. :>

Cheers,
Kendall

Received on Wednesday, 29 July 2009 18:19:39 UTC