The tricky part might be efficiently querying the number of edits for up to 5000 pages. Is SELECT rev_page, COUNT(*) FROM revision WHERE rev_page IN (/* 5000 integers */) GROUP BY rev_page efficient enough?

Typically an API client that needs this information would just hit prop=revisions&rvprop=&rvlimit={$X+1} (where $X is the most it cares about) and see how many revisions get returned.

Wait we query the database for this? Can we not store this as a page property and update it on save/move/edit?

Such a thing could be done, if someone wanted to do it.

The implementation in InfoAction makes the DB query (plus several more queries) for the one page and caches it; the API implementation could potentially reuse this cache when it exists, if hitting 5000 cache keys isn't a problem; populating the cache would require making all the queries that InfoAction does, which again would potentially be a lot of work.

Even if a lot of work it seems like it would be a valuable thing to do.

@Jdlrobson: Hmm, I don't see this task listed under https://www.mediawiki.org/wiki/Developer_Wishlist/2017 - could explain why you added Developer-Wishlist?

It was my understanding Developer-Wishlist was a project developers could add items to over the course of the year for nomination for the following year (in this case 2018) rather than during a specific week where they may not remember what's causing them pain and Developer-Wishlist (2017) was the project capturing the results for 2017.

It was my understanding Developer-Wishlist was a project developers could add items to over the course of the year for nomination for the following year (in this case 2018) rather than during a specific week where they may not remember what's causing them pain and Developer-Wishlist (2017) was the project capturing the results for 2017.

I've created a sub-project for proposals for the next run of the developer wishlist and moved this there.

Just going through some old bugs and I can update that there are still no edits in action=info

I don't think prop=info in the Action API and the action=info parameter to index.php should be thought of as different expressions of the same thing. The code paths are completely different, the features are quite different, the engineering constraints are quite different due to the API being batched...

For the creation date you can use prop=revisions already.

My latest use case is https://skins.wmflabs.org - I want to sort skins by number of edit and created date but the API doesn't help me do that.

I am aware about using revisions, but what I really want is quick look up of created date and number of edits so I can obtain and sort by the above fields on a query like so:
https://www.mediawiki.org/w/api.php?action=query&format=json&origin=*&prop=pageimages%7Ccategories&formatversion=2&origin=*&clcategories=Category:Skins_that_have_additional_setup_requirements%7CCategory:Skins_which_require_code_modification%7CCategory:Skins_using_deprecated_features&cllimit=50&piprop=thumbnail&pithumbsize=400&pilimit=50&generator=categorymembers&gcmlimit=50&gcmtitle=Category%3AStable_skins&gcmnamespace=106

Showing the date of the first edit would be the same query as in T147676#2705959, just with MIN(rev_timestamp) instead of COUNT(*), with the same performance issue - you'd have to filesort [sum of edit count of up to 5000 pages] rows. That's easily millions. I guess the limit could be reduced to something like 50 for expensive properties, and then it's a more manageable amount.

Yeh I understand it would be expensive. If we were to do this we'd presumably need to save this meta data once as a page property rather than running a query on every item. For created that only needs to happen on first edit and edit count on every edit (presumably that would allow optimization of the action=info page).

Plus undeletion, partial deletion, history merge, import. But most of those require reparsing, so I think you'd get them for free. Not quite sure about history merge.