Re: ldp wishlist for crosscloud - QUERY HTTP verb

Thank you, Henry!
My note was a bit of devil's advocacy.
There are, in fact other reasons why the
query parameter route is not ideal.

1.  It exposes some of the structure of the resource
in the URL which may be a security risk.
2. Some queries exceed the 4096K URL limit.

So, yes, a QUERY verb would be preferable.
How difficult would this to get through?
We could ask Mark Nottingham.
All the best, Ashok

On 11/10/2014 1:29 PM, henry.story@bblfish.net wrote:
>
>> On 10 Nov 2014, at 15:05, ashok malhotra <ashok.malhotra@oracle.com <mailto:ashok.malhotra@oracle.com>> wrote:
>>
>> Re. Query, why isn't a query string sufficient to express (simple) queries?
>> Trying to get a new verb approved seems like a long, hard road.
>> Ashok
>
> Hi Ashok,
>
>   thanks for giving me the opportunity to gather the different arguments I put
> forward in this thread, that were perhaps dispersed over the place.
>
> Syntax and Content-Negotiation
> ========================
>
> For one the HTTP QUERY verb does of course not remove the need for a
> query syntax. On the other hand the advantage of the HTTP verb is that
> it is syntax agnostic, due to HTTP supporting Content Negotiation.
> So one could use SPARQL as the Query language, XPath, some JSON
> query syntax such as  perhaps jaql or whetever is widely adopted there [1].
>
> For our interest let us take SPARQL as the appropriate syntax.
>
> Usually  you would query and LDPR Source perhaps with a query such as
>
> QUERY /henry/foaf HTTP/1.0
> Content-Type: application/sparql-query
> Content-Length: 78
>
> CONSTRUCT { ?p ?rel ?o . }
> WHERE {
>    <#hjs> foaf:knows ?p .
>    ?p ?rel ?o .
> }
>
> Or if you were to query an LDPC you could run a query
> such as the following to get just to what you needed in
> the LDPC:
>
> QUERY /ldpc HTTP/1.0
> Content-Type: application/sparql-query
> Content-Length: 78
>
> SELECT ?ldpr
> WHERE {
>    <> ldp:contains ?ldpr .
>     ?ldpr dc:author <http://example.org/joe#me> .
>    GRAPH ?ldpr {
>       ?ldpr a ping:Notification .
>    }
> }
>
>
> Why the HTTP QUERY verb?
> ======================
>
> So that leaves the question why not have every resource link to another resource
> on which one can then send the query. Of coures the same question can be asked
> as to why not have a link to a resource where one can PATCH, DELETE, or PUT
> And that should of course give you the reason as to why a verb can be interesting.
>
> Here are the arguments I put forward to answer that question, and that fall under a few
> groups: epistemological ones ( how do I know that a resource is going to do what I ask it
> to? ), pragmatic ( how do I avoid the resource being out of sync? ), and caching ones.
>
> The advantage of a verb is that you reduce the number of resources down to a
> minimum, and it reduces epistemological dissonance.
>
> So if I want to query a particular resource I don't have to worry that one resource
> is pointing me to another one that is out of sync, that now for some reason does
> something very different from what I thought it was going to do: perhaps POSTing
> a QUERY there now archives it. How does one do conditional QUERY on another resource?
>     ( of course there is some way one can do it, but how much more complicated
>      is it over just doing the right thing )
> This would also be a nice way to make SPARQL fully RESTful.
>
> The HTTP verbs form part of what in philosophy of language were called Speech acts.
> And in those one usuall found a few general types:
>   - declarative expression of something ( similar to GET )
>   - the making of something something, eg. a marriage "You are now man and wife" (POST)
>   - asking a question ( QUERY )
>   - ordering something to happen
>   - taking something back ( PATCH ? )
>
> Anyway it feels like this is the right level to do something, and I'd say that
> given that it was considered very early on in HTTP may give it a lot more weight
> than other methods. That's why I pointed here:
> http://www.w3.org/Protocols/HTTP/Methods.html
>
> So how does QUERY relate to the other verbs?
> ===================================
>
>
> consider that SPARQL UPDATE naturally falls under the HTTP PATCH verb,
> whereas a SPARQL Query naturally falls under the HTTP QUERY verb.
>
> They have very different HTTP caching effects.
>
> - A PATCH with SPARQL Update that succeeds naturally invalidates all caches
>   along the way but a QUERY that succeeds naturally does not. ( something
>   that won’t  be expressible in the link scenarios )
>
> - a series of QUERIES on graphs resources could end up leading a cache to
>   the full version of the graph. One could imagine the cache keeping answers
>   to the queries and appending them ( as long as the etag does not change )
>   calculating a strong graph hash for the results it had cached. At some point
>   that hash could match the remote hash and the cache would know it had all
>   the information. Ie a series of QUERIES at the limit is equivalent to a GET.
>
> - POST is really about creating new resoures, but when you do a QUERY you
>   are not really creating a new resource, you are getting a version of the existing
>   resource. So using POST for QUERIES as for PATCHes is not good HTTP.
>
> I think one could add to the list of arguments starting from first principles
> to explain why QUERY was in the initial HTTP specs.
>
>
> How difficult is it to deploy
> ====================
>
> I answered James Snell’ question
>
>
>>> The key challenge for pushing new http methods through is implementer support.
>>> Some popular platforms (like node.js for instance) do not have great support
>>> for extension methods.
>>
>> That sounds like a lesser problem. Node.js is open source and can be changed,
>> if developers are enthusiastic about it. For example to get node.js people
>> enthusiastic one could get them to consider that QUERY could work with their
>> favorite JSON query language - perhaps https://code.google.com/p/jaql/ ( not sure
>> what is hot there at present )
>>
>> The more difficult problems would be the caching infrastructure, though that is less
>> important as it used to be with HTTPS everywhere gaining ground.
>>
>> Also I am not against creating a standard link relations that do the job where
>> the methods cannot be  used, as a transition solution. It is just that I think one
>> should be clear about what the correct web architectural solution would be, and
>> let that guide one. It helps one think much more clearly about what is going on.
>> For example here about what SPARQL is doing and perhaps how LDP can
>> simplify SPARQL. ( eg: remove DELETE GRAPH from SPARQL specs and move
>> it to HTTP ).
>
> That’s about as much as I can think of for the moment. I hope it helps.
>
> [1] https://code.google.com/p/jaql/
>
>
> Social Web Architect
> http://bblfish.net/
>