Re: Pagination (ISSUE-42)

Hi All,

I've been silent observer, but seeing the paging support in Hydra was
something that I immediately felt uncomfortable with.

I find paging an artificial construct that requires unnecessary translation
and meta data. In my api's and clients I much prefer to use offset and
limit as a more fundamental concept to partial collections. It just becomes
two query parameters on a collection resource, more or less like a filter
constraint. I have found that offset/limit is a far easier paradigm to use
with 'fetch-more', 'infinite scroll', 'velocity scroll prediction' and
'back filling' use cases given that viewport/page sizes can change with
screen orientation. Sparse arrays in clients are easier to implement and
demand fill as there is no pre-conceived notion of a 'page size' that needs
to be configured down to the api layer.  Offset and limit is also how SQL
databases tend to handle these things and I believe some of the drivers
that led the SQL world to use a paradigm of offset and limit vs paging
equally apply here.

Regards,

Andrew


On Tue, Feb 3, 2015 at 8:48 AM, Markus Lanthaler <markus.lanthaler@gmx.net>
wrote:

> Hi folks,
>
> As announced (and promised) for a while, I would like tackle pagination
> next. While implementing Linked Data Fragments, Ruben made an interesting
> observation, namely that by just giving someone the URL of a
> "PagedCollection" it is unclear whether it is a single "page" or a
> "collection of pages". His proposal was to rename hydra:PagedCollection to
> hydra:Page and to introduce two new properites hydra:pageOf and
> hydra:hasPage. A paginated collection would then look as follows in JSON-LD
>
>   {
>     "@id": "http://api.example.com/an-issue/comments?page=3",
>     "@type": "Page",
>     "previousPage": "/an-issue/comments?page=2",
>     "nextPage": "/an-issue/comments?page=4",
>     "pageOf": {
>       "@id": "http://api.example.com/an-issue/comments",
>       "@type": "Collection",
>       "firstPage": "/an-issue/comments?page=1",
>       "hasPage": "/an-issue/comments?page=4",
>       "lastPage": "/an-issue/comments?page=498"
>     },
>     "member": [ ...]
>   }
>
> In contrast, with the current design it would look as follows
>
>   {
>     "@id": "http://api.example.com/an-issue/comments?page=3",
>     "@type": "PagedCollection",
>     "firstPage": "/an-issue/comments",
>     "previousPage": "/an-issue/comments?page=2",
>     "nextPage": "/an-issue/comments?page=4",
>     "lastPage": "/an-issue/comments?page=498",
>     "member": [ ...]
>   }
>
> The advantage of Ruben's proposal is that it becomes possible to address
> the
> whole collection as well as individual pages. With the current design
> that's
> not possible. The property referencing a PagedCollection would need to
> define what is meant. The advantage is an overall simpler design that
> aligns
> more closely with what developers are used from Atom or even HTML pages.
>
> Another design I have been tinkering with was to rename PagedCollection to
> something like PartialCollection and *perhaps* move the pagination controls
> into a separate resource or blank node:
>
>   {
>     "@id": "http://api.example.com/an-issue/comments?page=3",
>     "@type": "PartialCollection",
>     "pagination": {
>       "firstPage": "/an-issue/comments",
>       "previousPage": "/an-issue/comments?page=2",
>       "nextPage": "/an-issue/comments?page=4",
>       "lastPage": "/an-issue/comments?page=498"
>     },
>     "member": [ ...]
>   }
>
>
> I would propose we collect alternative designs and then discuss all of
> them.
> I created a Wiki page to collect the designs.
>
>    https://www.w3.org/community/hydra/wiki/Pagination
>
> If you have something to propose, please add it to the page but *also* send
> it to the mailing list. I would say we collect designs till the end of the
> week and start discussing them beginning of next week. I'm also open to
> other proposals on how to address this process-wise.
>
>
> Cheers,
> Markus
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>