tl;dr: add a new config variable, "RestModuleOverrides", to override the functionality set applied to particular REST modules. See the parent task for context.

Details

Specifying an audience designation for a REST module associates it with a specific functionality set. Modules without a specific audience designation will (after the initial rollout/transition period) have the "public" functionality set applied.

In some cases, we may want to override this and apply a different functionality set to specific modules, sometimes on a per-wiki basis. Introduce the RestModuleOverrides config variable for this purpose.

RestModuleOverrides will look something like this:

'wgRestModuleOverrides' => [
	'default' => [
		'mymodule.v1' => 'disabled',
		'myothermodule.v2' => 'discoverable',
		‘site.v1’ => ‘hidden’
	],
	'+testwiki' => [
		'mymodule.v1' => 'published'
	],
],

Notice in the above example that enabling a module on only a subset of wikis means setting it to 'disabled' by default, then selectively enabling it on the desired wikis. For the common case of REST APIs in extensions where the REST module should be enabled everywhere the extension is enabled, this will be unnecessary - if the extension isn't enabled on a wiki, there's no REST module to disable. But in other cases, such as modules in core that should only be enabled on some wikis, or for extensions that expose REST modules that should only appear on some wikis (ex. WikimediaCustomizations), this pattern will be needed.

The array_replace_recursive merge strategy will be needed to make this pattern work. See the PasswordPolicy variable for an example.

Opt-In

(TBD)

Notes

Initially, all audience designations will be mapped to the "discoverable" functionality set, and the existing RestSandboxSpecs and RestApiAdditionalRouteFiles config variables will continue to function unchanged. This means that RestModuleOverrides can be introduced with an empty default value and no associated config change without altering existing production behavior.

No errors should occur if RestModuleOverrides references a module that does not exist. It will sometimes be necessary to pre-deploy a config change to RestModuleOverrides before enabling the associated module. For example, imagine a new module with the "beta" audience designation that should not be published to the REST Sandbox. The workflow to accomplish this would be to first deploy a config change to RestModuleOverrides making the module unpublished (either "discoverable" or "hidden" depending on the specific need), and then a core/extension change to enable the module. If the code that processes RestModuleOverrides threw an error for the non-existing module, this workflow would not be possible.