Re: can GET do for QUERY? extending Partial Content

> On 29 Apr 2015, at 19:08, Willy Tarreau <w@1wt.eu> wrote:
> 
>> 
>> Again defining something that is undefined does not break a standard.
>> The latest spec says that GET can have Content-Length header. Presumably
>> the people allowing this had their reasons. Perhaps this is it.
> 
> The first reason is to simplify the implementations : when you see that
> you have no reason for doing a special case of GET when you already support
> POST, PUT and any other method supporting a body, you ensure that it works
> just like the other ones. Conversely, when you don't expect to need a body,
> you simply don't implement this at all and whatever follows the headers is
> processed in the easiest way for your implementation. I used to see a NAS
> segfault when receiving a body after a GET request or even pipelined GET
> requests, I've seen products block the body (and wrote one which used to),
> others will silently drop it. In fact you're very lucky when you get an
> error because you can react quickly. All other cases are painful because
> users say "it doesn't respond, even after one minute" and nobody knows
> where to look at.

It would not matter if servers blocked or dropped the body, since the client
would still get the full response and this proposal is that if it understood
the body it would just send partial content. This is no different from a client
asking for Partial Content and receiving instead the full content in one go.
Also the fact that you had to fix software that failed when receiving bodies
in GET means that you were not the only one to do that, so that most software
actually can withstand these now, or would have gone out of buisness from this.

Anyway as mentioned there is a fallback position using headers which would
look something like this

GET /People/Berners-Lee/card HTTP/1.1
Host: www.w3.org
Query: DESCRIBE <http://www.w3.org/People/Berners-Lee/card#i> 
Query-Lang: application/sparql-update
Vary: Query

That is I think the type of query that will be the most used in the
applications I am working on. If the client gets the whole body back,
that is not really a problem. The Query is there just to get the minimal
bounded graph around Tim Berners Lee's WebID, ie a subset of the
original graph.

This is completely resource bound, there is no change of scope,
and so it satisfies Roy Fielding's requirements. It satisfies your
requirement that there is no body sent. It also is efficient since
a client can make the GET request on a newly discovered resource 
and receive either the partial representation that it would prefer 
for efficiency sake or the full representation by a non query aware server. 
All of this without making a extra request to the server, which is important
for very strongly peer to peer usages which we need for the distributed
social web, if we don't all want to live forever in a police state (
we can discuss the implictions of this and how it relates to Snowden's
revelation around a beer in Prague ). The fact that both of these results
is ok for the client is in fact the proof that this is functioning
RESTfully.

For those who wish to live more dangerously, or who need more space for 
larger queries, putting the content in the body would be another option. 
If we formalise it now we can expect that in 5 to 10 years time it may 
indeed work perfectly.

Does this answer your concerns?

Henry


Social Web Architect
http://bblfish.net/

Received on Wednesday, 29 April 2015 22:19:23 UTC