On 09/16/2014 04:10 AM, "Martin J. Dürst" wrote:
> Hello Sandro, others,
>
> On 2014/09/16 10:13, Sandro Hawke wrote:
>> Earlier today the LDP Working Group discussed the matter of whether we
>> could use range headers instead of separate page URIs. Use of Range
>> headers was suggested on this list recently.
>>
>> Our conclusion was still "no", for the following reasons. Please let us
>> know if you see a good solution to any/all of them:
>>
>> 1. We don't know how the server would initiate use of Range. With our
>> current separate-page design, the server can do a 303 redirect to the
>> first page if it determines the representation of the entire resource is
>> too big. The question here is what to do when the client didn't
>> anticipate this possibility. True, the 303 isn't a great solution
>> either, since unprepared clients might not handle it well either.
>> Perhaps one should give a 4xx or 5xx when the client asks for a giant
>> resource without a range header...? But there's no "representation too
>> big" code defined.
>
> Can't you still use a 303 if there's no indication that the client
> understands tuple ranges?
>
What Location would the 303 redirect to? With Range, the individual
sub-parts wouldn't have their own URIs.
Maybe it would redirect to a page which explained that the resource was
too big, and gave some metadata, possibly including the first few and
last few elements.
>> 2. We don't know how we could do safe changes. With our current
>> design, it's possible for the resource to change while paging is
>> happening, and the client ends up with a representation whose inaccuracy
>> is bounded by the extent of the change. The data is thus still usually
>> perfectly usable. (If such a change is not acceptable, the client can
>> of course detect the change using etags and restart.) This bounded
>> inaccuracy a simple and practical concept with RDF (in a way it isn't
>> with arbitrary byte strings). Just using Range, a deletion would often
>> result in data unrelated to the change being dropped from what the
>> client sees.
>
> Why isn't this the case in your solution? In order to work, don't you
> essentially have to remember exactly how far the client read? If you
> have various clients, one that started before the first change, one
> after the first but before the second change, and so on, how is the
> server going to keep track of how far the client got?
>
You seem be to be thinking that pages are numbered.
Instead one can use HATEOAS and embed a place marker in the next and
prev URIs. If those place markers are data values instead of indexes,
then insert/delete are handled properly.
This is explained in: Received on Tuesday, 16 September 2014 18:20:44 UTC