Except that every goddamn webapp completely fucks up pagination! They all implement the completely braindead pattern where the most recent N posts are on page 1, and then count up into the past. The resources found on "Page 2" get pushed down every time a new item is posted.
It really couldn't be any shittier, and only a handful of people have ever implemented anything else. It also makes it impossible to usefully cache the whole page, which is just deadly for an API.
At minimum, your page numbers should be in the same reverse order that your content is. A better implementation is to have the pages represent fixed periods of time (hours/days/weeks/months/years).
It's better to not expose paging in the UI than to cock it up like everyone else. Having real links to "Page 2" in Twitter's timeline would be a terrible idea -- it would be anything but a permalink, as the content would change completely 20 tweets later.
I would totally get behind one page = a given time window, as long as the time window is configurable, or at the least, page n is an offset from what was the first item on the first page when you started paging.
It really couldn't be any shittier, and only a handful of people have ever implemented anything else. It also makes it impossible to usefully cache the whole page, which is just deadly for an API.
At minimum, your page numbers should be in the same reverse order that your content is. A better implementation is to have the pages represent fixed periods of time (hours/days/weeks/months/years).
http://www.dehora.net/journal/2008/07/20/efficient-api-pagin... is the only clear elucidation of this insanity I've seen.
It's better to not expose paging in the UI than to cock it up like everyone else. Having real links to "Page 2" in Twitter's timeline would be a terrible idea -- it would be anything but a permalink, as the content would change completely 20 tweets later.