Re: Query Verb Proposal

Hi Henry:
I am forwarding this to James Snell because he came up with the example
and will be able to defend it better than I can.  I will respond to your
comment on cacheing separately.

All the best, Ashok

On 3/27/2015 8:47 AM, henry.story@bblfish.net wrote:
>
>> On 25 Mar 2015, at 23:52, ashok malhotra <ashok.malhotra@oracle.com> wrote:
>>
>> Please review the first draft of the Query Verb Proposal at:
>> https://github.com/jasnell/specs/blob/master/httpbis/draft-snell-search-method-00.txt
>>
>> This is a minimalistic proposal since it was felt that a smaller proposal had a better
>> chance of being accepted than a more complex proposal.
>>
>> Many different query syntaxes can be supported.  Each with its own media type.
>
> Looks very good.
>
> Here are some questions:
>
> • section 2: "The response to a SEARCH request is not cacheable.  "
>
> I suppose that is because a search may go beyond the limit of the resource requested,
> e.g. I suppose you could do a SEARCH on an LDPC that queries the LDPC but also the
> content. In that case the LDPC state may not change, but the results would differ.
>
> I suppose there could be cases where it was cacheable: e.g. when querying an LDP Graph.
> I wonder if there is a way to distinguish those two cases... Perhaps it would require
> a weak container etag, so that any change to the contained resources would change that
> etag.
>
> • section 4.1
>
> I think if one is to start with an example one really should start with a really good
> and simple one.  But this one has exactly the wrong feel
>
> ```
>    SEARCH /query HTTP/1.1
>    Host: example.org
>    Content-Type: application/sparql-query
>    Accept: application/ld+json
>
>    PREFIX foaf:  <http://xmlns.com/foaf/0.1/>
>    SELECT ?name ?email
>    FROM <http://www.w3.org/People/Berners-Lee/card>
>    WHERE {
>        ?person foaf:name ?name .
>        OPTIONAL { ?person foaf:mbox ?email }
>    } ORDER BY ?name LIMIT 10 OFFSET 10
>
> ```
>
> This feels wrong because you are sending a query onto a specialised query
> resource, where the point of the SEARCH verb ( "QUERY" would make this a bit
> clearer  here ) would be to query the resource directly. That is the
> prototypical query should be
>
> ```
>    SEARCH /People/Berners-Lee/card HTTP/1.1
>    Host: www.w3.org
>    Content-Type: application/sparql-query
>    Accept: application/ld+json
>
>    PREFIX foaf:  <http://xmlns.com/foaf/0.1/>
>    SELECT ?name ?email
>    WHERE {
>        ?person foaf:name ?name .
>        OPTIONAL { ?person foaf:mbox ?email }
>    } ORDER BY ?name LIMIT 10 OFFSET 10
> ```
>
> This allows you to give an extra reason for the QUERY verb:
> that you are not going through a third party resource, which may
> be out of sync with the resource itself. Querying one resource about
> another is a very special case of a very special type of resource.
>
> It also makes for a better RESTful story, and would allow some
> better integration with the caching layer. It would also tie
> in much more nicely with LDP. It would allow you to argue that
> SEARCH is to GET what PATCH is to PUT.
>
> Hope this helps,
>
>
>  Henry
>
> Social Web Architect
> http://bblfish.net/
>
>> --
>> All the best, Ashok
>>
>
>
>

Received on Friday, 27 March 2015 15:11:11 UTC