REST: Audience Designations - Visually separate "opt-in" modules in the REST Sandbox
Open, Needs TriagePublic
Actions

Assigned To

None

Authored By

	BPirkle
	Apr 9 2026, 7:28 PM

Project Tags

Referenced Files

None

Subscribers

Description

tl;dr: adjust the REST Sandbox to visually separate certain modules, requiring the user to proactively choose to see them. Use this for "beta" and "internal" audience designations.

Details

Note: we may choose to split the following work into several subtasks.

Certain REST API modules are not intended for general, long-term use by public callers. These include "beta" modules, which should exist for only a limited amount of time, and "internal" modules, whose stability and versioning is subject to the needs of internal WMF teams and therefore may be undesirable for general public use.

To prevent confusion or accidental adoption of these endpoints, while still allowing their documentation to be presented, we will require users to take proactive action in order to see these "opt-in" modules in the REST Sandbox.

We should first determine how to visually present opt-in modules, how users will go about choosing to view them, and what internal changes may need to be made to the data communicated to the REST Sandbox Special Page by ModuleManager to allow this.

We should then implement this system.

Finally, we should use this for "beta" and "internal" modules by default.

Checklist

Determine a visual and functional design for separating "opt-in" modules
Implement this in the REST Sandbox
Remap the "beta" and "internal" modules to the "opt-in" functionality set.

Related Objects
Search...

Status	Assigned	Task
Open	None	T422400 [Hypothesis] 5.2.8b: API Module Refinement
Open	None	T422551 REST: Audience Designations - technical implementation
Open	None	T422873 REST: Audience Designations - Visually separate "opt-in" modules in the REST Sandbox

Event Timeline

BPirkle created this task.Apr 9 2026, 7:28 PM

BPirkle moved this task from Incoming (Needs Triage) to To Refine on the MediaWiki-API-Platform-Team board.Apr 9 2026, 10:17 PM

HCoplin-WMF moved this task from To Refine to Backlog on the MediaWiki-API-Platform-Team board.Apr 21 2026, 2:54 AM

BPirkle mentioned this in T422551: REST: Audience Designations - technical implementation.Apr 21 2026, 3:10 PM

Slack comment by @aaron :

One thing we should do anyway is get rid of the dropdown+button and just generate a list of one-click links. Then, you could have them under headings based on topical group. When we end up with a ton of APIs,  it seems fine to have a JS checkbox/dropdown that filters in 3 possible ways (public APIs, internal APIs, both). That would be good enough as I doubt that we will have a huge amount of beta or deprecated modules that it is worth having checkboxes to hide them.

beta/deprecated stuff should get different CSS classes, so I guess one still needs a way to convey that in config.

I'd like to get input from an actual designer before we start this task. Even if we can't get a full layout, a but of quick "do this, not that" guidance would be helpful. Aaron's comment seemed useful to keep in mind as a possibility. Long-ish lists of one-click links are pretty common in MediaWiki.

Implementation thought: as much as possible, we want handling of the RestModuleOverrides config variable and the behaviors associated with audience designations to be contained with ModuleManager. The REST Sandbox currently gets the array of specs to display (and the display name for each) from ModuleManager. This might make the backend handling of opt-in groups conveniently handled by modifying the ModuleManager::getApiSpecDefs() return value to include a group key.

BPirkle mentioned this in T422754: REST: Audience Designations - functionality sets.May 14 2026, 9:49 PM

REST: Audience Designations - Visually separate "opt-in" modules in the REST SandboxOpen, Needs TriagePublicActions