Include [[https://wikitech.wikimedia.org/wiki/Analytics/PageviewAPI|Pageview API]] data into the action API. Use cases:
* allow convenient access by the various tools (PWB, mw.Api etc) which already implement an interface to action API
* for products which already need to fetch page information from the action API, allow freeriding on that request to get pageview data
* (probably) get pageview information for a list of pages in a single request
* (maybe) use pageview information to filter/sort lists, e.g. most viewed pages in a given category
This will probably mean three new API modules:
* a meta module for returning site totals (the `aggregate` endpoint` of the Pageview API)
* a list module for returning most viewed pages (the `top` endpoint)
* a prop module for getting per-page view data (the `per-article` endpoint)
Per earlier email discussion, we probably want to avoid the complexity of arbitrary date ranges and just return some commonly used ranges (e.g. daily sums for the last 60 UTC days, with a 2-day offset to avoid incomplete results). We probably also want to disallow useragent/access-mode filtering.
Batch data access would require copying pageview data into some kind of cache (memcached or DB) in a job; on-demand caching is unrealistic as a batch request can include thousands of articles (the action API typically has a limit of 5000 for bots) and the Pageview API only return data for one article per request. Filtering based on pageview data would require using the DB as a backend.
This is a Q2 goal for Reading Infrastructure.