Re: ldp-ISSUE-33 (pagination): how to structure functionality

hello ashok.

On 2012-11-12 8:09 , "Ashok Malhotra" <ashok.malhotra@oracle.com> wrote:
>FWIW, Odata has a different approach to pagination.
>LDP suggests a separate URI for each page, for example .../#n
>OData give you a pointer at the bottom of each page to the next page.
>Not sure if there is a pointer to the previous page.  Need to check the
>spec.

fwiw, rfc5005 does not tell you what the page URIs look like at all, and
that's how things should be: URIs must be opaque. rfc5005 just says that
if there is a link to a next page, it can be found following the "next"
link. whether that points to .../page2 or .../page#2 or ...?page=2 is an
implementation issue, and clients simply follow whatever link they find
when they want to GET the next page.

interestingly, this only works if the semantics are fixed (such as "next
page"). what this scheme doesn't support is parametrized semantics, such
as "how to get to page 42". if this was to be supported, the proper web
way would be to use a URI template, have a parameter in there that
specifies the page number (which could interoperate with another parameter
specifying the page size), and then clients could pick the parameter
values they are interested in, instantiate the URI template, and the
resulting URI would take them to page 42.

for atom, a standardized mechanism for that latter approach (paging++ with
parameters such as page size and random access to pages) does not exist
(yet), but we're actively working towards such a thing. the current idea
is that it uses and extends rfc5005, and then uses rfc6570 to define
parameters that clients can use to compose meaningful URIs at runtime,
purely based on runtime information found in URI templates.

cheers,

dret.

Received on Monday, 12 November 2012 17:31:54 UTC