tl;dr: activating a REST module in core previous required a config change/deploy. It can now be done in core code, but in some cases config is currently still used. Make this consistent, and prepare to eliminate the RestAPIAdditionalRouteFiles config variable.
Details
When the REST framework was introduced, it did not include the concept of REST modules. instead, endpoints were defined in "route files". These endpoints were then all combined internally into the set of available routes. The endpoints defined in these files were enabled by referencing the file in the RestAPIAdditionalRouteFiles config variable (for core routes) or the associated extension.json (for routes in extensions).
This resulted in a large number of routes with comingled versions, large, difficult-to-read OpenAPI specs, and a confusing set of unrelated endpoints in the REST Sandbox. It also meant that REST modules in extensions could be activated without a separate config change/deploy, while core modules did require a config change/deploy. REST modules addressed some of these concerns, but did not change the underlying system for enabling endpoints.
The ModuleManager class allowed enabling core modules in code without a config change. But because of an overzealous exception in Router, this was not used in all cases.
The RestModuleOverrides that will be introduced in T422756: REST: Audience Designations - add RestModuleOverrides config value provides a mechanism to clean this up.
Add the following core extensions to the hard-coded CORE_ROUTE_FILES list in ModuleManager:
- site.v1
- specs.v0
Make whatever changes are necessary to ensure that enabling these AND having them specified in RestAPIAdditionalRouteFiles will not cause an exception. Note that this must be done in core code - third party wikis may have these modules defined in their RestAPIAdditionalRouteFiles, and we don't want to cause an exception for these wikis.
Once this is done, we can remove mention of these modules from RestAPIAdditionalRouteFiles.
Also adjust enabling of REST modules in extensions to use an ExtensionRegistry attribute rather than internally modifying RestAPIAdditionalRouteFiles. This prepares for eventual deprecation and removal of RestAPIAdditionalRouteFiles. To do this, accumulate extension route files (by module file name) in an ExtensionRegistry attribute and process them in ModuleManager. See ForeignResourcesDir as an example of how this would work, including usage of the attribute.
content.v1
Handling of this module is TBD. It is speculative, and is currently enabled only on testwiki and beta via the RestAPIAdditionalRouteFiles config variable. We would prefer to stop using RestAPIAdditionalRouteFiles so that we can start its deprecation process.
Some options for what to do with content.v1, to discussion with product management:
- Turn it off. It receives essentially no traffic (Turnillo showed no hits in the last 30 days as of 2026-04-12). It will likely be reconsidered as part of the upcoming "v2" API work, and is therefore to ever be released in its current form. Turning it off would be the simplest solution.
- Switch to RestModuleOverrides. We could enable content.v1 by default in core, then disable it everywhere except testwiki and labs in config via RestModuleOverrides. A downside is that this is awkward for third party wikis. To maintain status quo for them, we'd need to set a default for RestModuleOverrides in core disabling it, which is a little unusual.
- Change it to beta. A content.v1-beta module could go live on third party wikis with less consequence. Still not great, given that we explicitly say we want betas to be short-lived, and content.v1 has been around a long time.
- Do nothing, and figure it out later.
- Something else I didn't think of. There are bound to be more choices.
Checklist
- ensure that enabling the same module via both ModuleManager::CORE_ROUTE_FILES and RestAPIAdditionalRouteFiles does not cause an exception (see subtask T423056: REST: Audience Designations - clean up module enabling - refactor Router::buildModuleMap() exception logic)
- change extension module enabling to not reference RestAPIAdditionalRouteFiles (see subtask T423057: REST: Audience Designations - clean up module enabling - refactor enabling for modules in extensions)
- enable site.v1 and specs.v0 via ModuleManager::CORE_ROUTE_FILES
- remove site.v1 and specs.v0 from RestAPIAdditionalRouteFiles in production
(see subtask T423058: REST: Audience Designations - clean up module enabling - enable site.v1 and specs.v0 in core by default for the last two checkboxs)
And possibly:
- do something with the content.v1 core module, per discussion with product management