Re: Pagination best practices

good morning;

> On 2017-05-23, at 09:10, Daniel Smedegaard Buus <danielbuus@gmail.com> wrote:
> 
> On 23 May 2017 at 08:19, james anderson <james@dydra.com> wrote:
>> good morning;
>> 
> 
> Good morning :)
> 
>>> On 2017-05-23, at 08:02, Daniel Smedegaard Buus <danielbuus@gmail.com> wrote:
>>> […]
>>> When I started out two weeks back, I also briefly considered the Range
>>> header, but there are a couple of reasons why I don't want to go that
>>> route:
>>> 1) The Range header has a completely different meaning
>> 
>> what are these two “completely different meaning[s]”?
>> 
> 
> Well, looking over the specs again, I guess you _could_ specify a unit
> like "User" instead of bytes, and convert the concept of a "page" to a
> "range" of sequential integers on that unit. But how would you include
> the total number of items, links to prev and next, etc. (especially if
> the IRIs use id-gnostic paging, such as ?after=a43bf007653aa1)?
> 
>>> 2) I have much more information that I want to convey and consume,
>>> such as number of pages, links to pages, sorting, etc., and they don't
>>> fit in there either.
>>> 3) HTTP headers are, well, HTTP-gnostic. I'd like my API to be
>>> transport-agnostic. And apart from that, putting pagination
>>> information in a header transfers state from the document to the
>>> transport layer, and I really want the API to offer REST in and of
>>> itself, and in all possible transport scenarios, be it HTTP, RPC, Unix
>>> sockets or carrier pigeons :D.
>> 
>> the api is not the model is not the transport.
>> 
> 
> Clearly :)
> 
>> in what way does the pagination relate to the way the model represents whatever it is that you intend that it should.
>> whenever i look at an entrained pagination encoding and ask that question, the answer has been “none”.
>> which leads to the question, “what is it doing there?"
>> 
> 
> I'm not sure exactly what you mean by model in this context, but the
> pagination links offer state transition. I want the documents I serve
> to be self-contained and RESTful.

we disagree, whether the transmission state has anything to do with the resource state.

> 
> Also, I don't know how you'd possibly deal with providing links to
> nested partial resources that can be paged in an accept header?

whatever expression you would want to choose, you will eventually linearize it in order to pack it into an http response body.
whether that is inline or not does not change its capacity to express ranges - even multiple ranges.

best regards, from berlin,
---
james anderson | james@dydra.com | http://dydra.com

Received on Wednesday, 24 May 2017 16:41:36 UTC