Re: Pagination best practices

good afternoon jerven;

> On 2017-05-22, at 14:45, Jerven Tjalling Bolleman <jerven.bolleman@sib.swiss> wrote:
> 
> Hi James,
> 
> On 05/22/2017 02:34 PM, james anderson wrote:
>> good afternoon,
>> 
>>> On 2017-05-22, at 11:07, Daniel Smedegaard Buus <danielbuus@gmail.com> wrote:
>>> 
>>> Hi guys :)
>>> 
>>> […]
>>> 
>>> How are you guys handling this in the most elegant and JSON-LD compliant way?
>> 
>> what are the arguments against using a range header?
> Range header support is practically only supported for bytes.
> i.e. you can say I want byte 5 to 10, but I think almost nothing supports I want result line 5 to 10.
> 
> Also there are some things in pagenation via IRI parameters that don't play nicely with range headers on a document.
> 

if the operation which interprets the iri arguments implements http range processing, there is no reason why conflict resolution logic would not be part of the protocol definition.
if it does not, then, yes, i would not expect them to interoperate.
on the the other hand, pagination in the request iri breaks the separation between the resource designation and the protocol level, which just makes it the wrong direction to go, in principle.
reading each new recommendation which introduces its own way to page and mixes that into the description of the operation to perform on its data source, does not do anything to convince - even if, as a convenience, it carries over from some underlying query language.
the better approach would be to recognize what http offers and expect that, in the context of http, the respective retrieval and projection operation does the right thing with it.
sparql somehow managed to conceive that is possible for the dataset specification.
other than your objection, above, which does not convince, i have seen none against that approach for paging as well.

best regards, from berlin,



---
james anderson | james@dydra.com | http://dydra.com

Received on Monday, 22 May 2017 13:25:16 UTC