Re: ldp wishlist for crosscloud - QUERY HTTP verb

Some quick thoughts from me on this thread....

For me it seems like it is too soon to start lobbying for a new HTTP method
when we don't have have a draft of a spec.  Sandro even mentioned needing
some time to flush the design out.

Regarding PATCH as an example, this started out as an extension to POST and
grew with enough demand that the PATCH method was standardized but support
is still limited.  Even saying you need QUERY, you have a long road to
getting it standardized let alone widely deployed.  I would suggest to
tunnel it through POST like PATCH was originally done, then that would give
you plenty of ammo when going forward for standardization.

Looking around at other standards that have introduced new query-related
methods, WebDAV comes to mind, I see they have the SEARCH verb [1] but its
definition is quite limited within that spec.

I also think it might be overstating it to say that POST means create,
therefore we need QUERY.  POST means many different things, though the
examples referenced by HTTP [2] lists mostly creation scenarios.  It is
quite often used to mean: transform, notify, query, ...

I'm not saying this QUERY method may not be a good idea, just not sure it's
something that I personally would put much energy into supporting.  You can
simply flag an end-point as accepting POST and accepting a certain format
(Accept-Post), though doesn't say whether you can execute or create queries
of that format, still need outside information.

[1]: http://tools.ietf.org/search/rfc5323#section-2
[2]: https://tools.ietf.org/html/rfc7231#section-4.3.3

- Steve


On Mon Nov 10 2014 at 1:31:35 PM henry.story@bblfish.net <
henry.story@bblfish.net> wrote:

>
> On 10 Nov 2014, at 15:05, ashok malhotra <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/
>
>