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

On Wed, Jul 29, 2009 at 1:18 PM, Kendall Clark<kendall@clarkparsia.com> wrote:
> 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.

I agree with you. I paraphrased the original, which indeed does not
use the word "length".

>From section 2.2:
"The queryHttpGet binding should be used except in cases where the
URL-encoded query exceeds practical limits, in which case the
queryHttpPost binding should be used."

>> 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.
> :>

While more consistent, it becomes awkward for a client that has to
know the method to use based on an update string that it is
processing, and annoying (though trivial) at the server end to ensure
that the appropriate commands were given with the appropriate HTTP
methods.

If you have something like the equivalent of a CLI (a use case I have
to support), then a single entry point on the server is a lot easier.
I think that POST is the only HTTP method whose semantics support
this.

>> 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. :>

It may do, and I acknowledge the point. However, there seems to be
popular support for a language that can perform updates (including
with my users), and the only network interface I like using these days
is HTTP. Hopefully, the inclusion of the REST-style interface will go
some way to mollifying those people you're referring to.

Regards,
Paul

Received on Wednesday, 29 July 2009 18:47:52 UTC