Re: can GET do for QUERY? extending Partial Content

> On 29 Apr 2015, at 21:48, Julian Reschke <julian.reschke@greenbytes.de> wrote:
> 
> On 2015-04-29 20:00, henry.story@bblfish.net wrote:
>> 
>>> On 29 Apr 2015, at 19:12, Zhong Yu <zhong.j.yu@gmail.com> wrote:
>>> 
>>> On Wed, Apr 29, 2015 at 11:53 AM, henry.story@bblfish.net
>>> <henry.story@bblfish.net> wrote:
>>> 
>>>> But hey if you and everybody else here thinks that deployment is the only
>>>> issue left here, then that would be good to know. :-)
>>> 
>>> It appears to me that the only problem SEARCH solves(or rather,
>>> avoids) is the limitation of URI length. That *is* a deployment issue.
>>> 
>>> So GET is fine, it's just constrained by the current deployments for
>>> your use cases. You want a workaround, which, nevertheless, works
>>> through *the current deployment*.
>> 
>> Ok, we do have a workaround. Andrei Sambra and Sandro Hawke who are closely
>> with Tim Berners Lee at the Distributed Information Group at MIT, have started
>> working a couple of weeks ago on  a proposal for a platform called SoLiD
>> ( Social Linked Data )  with which we can build the disitrubted secure social web.
>> This is described in a very early form in this document
>> 
>>   https://github.com/linkeddata/SoLiD
>> 
>> There they have been playing with moving the query to the headers presumably
>> to avoid the problem discussed here. The query looks like this:
>> 
>> GET /data/ HTTP/1.1
>> Host: example.org
>> Query: SELECT * WHERE { ?s ?p ?o . }
>> 
>> and the response looks like this:
> 
> There are constraints on header field sizes as well. So this may work a *bit* better than URI parameters, but it will hit some limit as well.
> 
> The result will need to vary on "Query", so it won't be cached a lot.
> 
> Also don't forget to think about non-ASCII characters in the header field.

Thanks. 
Can one make the result vary on the body too?

> 
>> HTTP/1.1 200 OK
>> 
>> {
>>   "head": {
>>     "vars": [ "s", "p", "o" ]
>>   },
>>   "results": {
>>     "ordered" : false,
>>     "distinct" : false,
>>     "bindings" : [
>>       {
>>         "s" : { "type": "uri", "value": "https://example.org/data/" },
>>         "p" : { "type": "uri", "value": "http://www.w3.org/1999/02/22-rdf-syntax-ns#type" },
>>         "o" : { "type": "uri", "value": "http://www.w3.org/ns/ldp#BasicContainer" }
>>       },
>>       {
>>         "s" : { "type": "uri", "value": "https://example.org/data/" },
>>         "p" : { "type": "uri", "value": "http://purl.org/dc/terms/title" },
>>         "o" : { "type": "literal", "value": "Basic container" }
>>       }
>>     ]
>>   }
>> }
>> 
>> I imagine we could use this as a fall back position to work around issues
>> if they appear. One would need to specify the query mime type too in a header
>> of course.
>> 
>> This would limit the query sizes quite dramatically, and does not feel as good
>> as the GET with body. So if we were to specify this in an RFC one could have
>> either a fallback RFC for the intermediate stage, or specify the fallback position
>> in the GET + query in the body RFC.
>> 
>> Would that work?
>> 
>> Henry Story
> 
> Or you could use SEARCH :-)

yes, SEARCH is another option. I have a feeling that we've pretty much covered the ground
in the last week here. 

I find GET more elegant for the moment long term but SEARCH can work too. I wonder
what the consensus is like on the WG.

I wonder also what we can do until the IETF meeting in Prague to make progress on this.

Henry

> 
> Best regards, Julian

Social Web Architect
http://bblfish.net/

Received on Wednesday, 29 April 2015 21:54:33 UTC