Change Details

Create endpoints for stable page content analogous to the endpoints for latest page content: * page/{title}/html -> page/{title}/{selector}/html * page/{title}/html_with -> page/{title}/{selector}/html_with For completeness, we should also support the source and meta-data endpoints: * page/{title}/bare -> page/{title}/{selector}/html_with * page/{title} -> page/{title}/{selector} Note that the `latest` field in the response body should be named `revision` in the new endpoints. The following values for `selector` should be supported: * "latest": same as the old endpoints, except for minor differences in the structure of the response body, for consistency. * "stable": provided by FlaggedRevs via a hook. Must use FlaggedRev's ParserCache. Uses the appropriate revision of templates and images, per the FlaggedRevs extension. * date: (future) a rendering of the page as it was at the given date (similar to the memento extension). Will never be perfect. * rev id: (future) a rendering of the page as it was at the time the given revision was saved. Will never be perfect, but should make an effort to use the appropriate old revision of templates as well. Context: * FlaggedRevisions introduce the concept of "stable" revisions, which are shown to the public per default. * The REST API doesn't have this concept, and it doesn't provide a goo way for FlaggedRevisions to hook in to support it. * Services like PCS want to base their output on the latest stable rendering, not the latest revision. Considerations: * While it is OK for page views in the browser to show different content based on whether the user is logged in, doing the same for a REST API seems dodgy. * We may in the future want to support multiple levels of stability, or getting content that for a given point in time. * We can't redirect to the revision endpoint, since a rendering of an old revision doesn't necessarily use the correct version of templates embdeed on the page. It would also bypass any specialized caches, such as the ParserCache segment reserved for FlaggedRevs. * A hook that provides handling for a revision selector should be able to provide a ParserOutputAccess (or ParsoidOutputAccess?) instance that implements the rendering and caching. For reference: * Joe's comment that led to this proposal: T321101#8352889 NOTE: before comitting to this, we should exploe whether we can solve the issue with FlaggedRevs in another way, e.g. by diosabling it on ruwiki.

Create endpoints for stable page content analogous to the endpoints for latest page content: * page/{title}/html -> page/{title}/{selector}/html * page/{title}/html_with -> page/{title}/{selector}/html_with For completeness, we should also support the source and meta-data endpoints: * page/{title}/bare -> page/{title}/{selector}/html_with * page/{title} -> page/{title}/{selector} Note that the `latest` field in the response body should be named `revision` in the new endpoints. NOTE: alternatives should be considered, e.g. using selectors instead of revision IDs in the revision endpoints, e.g. revision/{selector}/html. We should also consider using redirects for cacheability. The following values for `selector` should be supported: * "latest": same as the old endpoints, except for minor differences in the structure of the response body, for consistency. * "stable": provided by FlaggedRevs via a hook. Must use FlaggedRev's ParserCache. Uses the appropriate revision of templates and images, per the FlaggedRevs extension. * date: (future) a rendering of the page as it was at the given date (similar to the memento extension). Will never be perfect. * rev id: (future) a rendering of the page as it was at the time the given revision was saved. Will never be perfect, but should make an effort to use the appropriate old revision of templates as well. Context: * FlaggedRevisions introduce the concept of "stable" revisions, which are shown to the public per default. * The REST API doesn't have this concept, and it doesn't provide a goo way for FlaggedRevisions to hook in to support it. * Services like PCS want to base their output on the latest stable rendering, not the latest revision. Considerations: * While it is OK for page views in the browser to show different content based on whether the user is logged in, doing the same for a REST API seems dodgy. * We may in the future want to support multiple levels of stability, or getting content that for a given point in time. * We can't redirect to the revision endpoint, since a rendering of an old revision doesn't necessarily use the correct version of templates embdeed on the page. It would also bypass any specialized caches, such as the ParserCache segment reserved for FlaggedRevs. * A hook that provides handling for a revision selector should be able to provide a ParserOutputAccess (or ParsoidOutputAccess?) instance that implements the rendering and caching. For reference: * Joe's comment that led to this proposal: T321101#8352889 NOTE: before comitting to this, we should exploe whether we can solve the issue with FlaggedRevs in another way, e.g. by disabling it on ruwiki.

Create endpoints for stable page content analogous to the endpoints for latest page content: * page/{title}/html -> page/{title}/{selector}/html * page/{title}/html_with -> page/{title}/{selector}/html_with For completeness, we should also support the source and meta-data endpoints: * page/{title}/bare -> page/{title}/{selector}/html_with * page/{title} -> page/{title}/{selector} Note that the `latest` field in the response body should be named `revision` in the new endpoints. NOTE: alternatives should be considered, e.g. using selectors instead of revision IDs in the revision endpoints, e.g. revision/{selector}/html. We should also consider using redirects for cacheability. The following values for `selector` should be supported: * "latest": same as the old endpoints, except for minor differences in the structure of the response body, for consistency. * "stable": provided by FlaggedRevs via a hook. Must use FlaggedRev's ParserCache. Uses the appropriate revision of templates and images, per the FlaggedRevs extension. * date: (future) a rendering of the page as it was at the given date (similar to the memento extension). Will never be perfect. * rev id: (future) a rendering of the page as it was at the time the given revision was saved. Will never be perfect, but should make an effort to use the appropriate old revision of templates as well. Context: * FlaggedRevisions introduce the concept of "stable" revisions, which are shown to the public per default. * The REST API doesn't have this concept, and it doesn't provide a goo way for FlaggedRevisions to hook in to support it. * Services like PCS want to base their output on the latest stable rendering, not the latest revision. Considerations: * While it is OK for page views in the browser to show different content based on whether the user is logged in, doing the same for a REST API seems dodgy. * We may in the future want to support multiple levels of stability, or getting content that for a given point in time. * We can't redirect to the revision endpoint, since a rendering of an old revision doesn't necessarily use the correct version of templates embdeed on the page. It would also bypass any specialized caches, such as the ParserCache segment reserved for FlaggedRevs. * A hook that provides handling for a revision selector should be able to provide a ParserOutputAccess (or ParsoidOutputAccess?) instance that implements the rendering and caching. For reference: * Joe's comment that led to this proposal: T321101#8352889 NOTE: before comitting to this, we should exploe whether we can solve the issue with FlaggedRevs in another way, e.g. by diosabling it on ruwiki.