Page MenuHomePhabricator

Core REST API page history endpoint should use opaque section markers for paging
Open, LowPublic

Description

Problem

The page history endpoint uses a revision ID in the newer_than and older_than query parameters in the URLs contained in the 'latest', 'newer', and 'older' fields of the response, to do paging/segmenting. Internally, it then loads the indicated revision, and uses that revision's timestamp to find revisions older or newer than it.

This is inefficient. Best practice is to use an opaque segment marker (or "continuation" in the action API). The idea is that the information necessary for efficient segmentation may depend on details of the database schema, and should be considered opaque to the client.

Solution

The page history endpoint should support a query parameter called "segment" that uniquely identifies a segment using an opaque identifier, similar to the one defined in T252202 for the user contributions endpoint. This "segment marker" would in practice include the timestamp and revision id (and possibly the step direction, and other information), but this should be irrelevant to the client.