So roughly what needs to be done here:
- Decide whether to expand list=random or make new module. New module might be better, as its difficult to map the existing module's notion of continuation to the category case, and the namespace filter might not be able to apply to categories that efficiently
- Make SpecialRandomInCategory::getQueryInfo be public instead of protected
- Call getQueryInfo in your api module. You may have to override the LIMIT parameter in options
- From there you have to add all the pages to the results of the api.
That's the status quo pattern, but long term this is not a pattern we want to preserve. We'd prefer to separate UI and backend functionality rather that having API modules call methods on special page classes.
The method used here is rather biased. It is assumed that the use of this page will be people wanting to get a random page out of a maintenance category, to fix it up. The method used by this page should return different pages in an unpredictable fashion which is hoped to be sufficient, even if some pages are selected more often than others.
A more unbiased method could be achieved by adding a cl_random field to the categorylinks table.
If the goal of the API is the latter, adding cl_random as an available parameter of cmsort to API:Categorymembers could be a solution.