Pagination and HTTP caching

“00f.net’s initial blog engine worked that way. Pages URIs were made of timestamps:

http://example.com/1298640310.html

The content of such a page is N documents whose timestamp is greater than or equal to 1298640310.

This scheme works pretty well, because pages can get easily cached and indexed. Pages that don’t get any update can keep the same URI forever.

An article added to the freshest page automatically causes the URI to change, without invalidating the previous URI.

Timestamps were good enough for this blog, but any increasing and globally unique identifier would be a good fit.

The downside of non-monotonically increasing ids is that while it’s easy to jump to older content (“next page”), it can be tricky to get links to previous pages (newer content) without falling into duplicate content or HTTP redirects. But for infinite scroll pagination style, it makes wonders…”