Re: ldp wishlist for crosscloud - QUERY HTTP verb -> SEARCH?

> On 11 Nov 2014, at 20:25, Steve Speicher <sspeiche@gmail.com> wrote:
> 
> 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.

Yes, that’s called a SPARQL endpoint :-) It’s well known and widely deployed. And there are 
other equivalent ones for other query endpoints.

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

very nice!

WebDAV was not the success that people had hoped it would be, but it is undeniably  widely deployed,
with some very successful protocols such as Subversion, the HTTP versioning protocol.

The SEARCH verb leaves everything open to the content type, so we can put a SPARQL Query
content type if we want to. The only requirement from the WebDAV spec is that  SEARCH be 
like GET,  ie. that it not modify the resource. Just what I was looking  for.


> 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, …

Yes, that is the problem with it, as specified by the PATCH RFC: it is too general.  
One can also think of it as always either appending to a resource, or creating a new one. So in that
case you think of every query as a new resource. This is why an intermediary cache cannot really 
aggregate the results from a number of queries to create  full view of the resource as it gets more information
about it: every resource query resource is independent of the others.

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

It looks to me that one probably does not need any support anymore for SEARCH: If it is in WebDAV 
then its deployed enough. And it has the right semantics for us.

So I just wanted this thread to make the group more conscious about the realisability of 
SEARCH, and the use of it.  Having done this work, I think we can take time to think it
through.

> 
> [1]: http://tools.ietf.org/search/rfc5323#section-2 <http://tools.ietf.org/search/rfc5323#section-2>
> [2]: https://tools.ietf.org/html/rfc7231#section-4.3.3 <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 <mailto:henry.story@bblfish.net> <henry.story@bblfish.net <mailto: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 <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 <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/ <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/ <https://code.google.com/p/jaql/> 
> 
> 
> Social Web Architect
> http://bblfish.net/ <http://bblfish.net/>

Social Web Architect
http://bblfish.net/