--- Comment #2 from Brad Jorsch <> ---

Add a method, something like "isInternalApi", to ApiBase that by default
returns false.

Add a boolean "includeinternal" parameter to ApiHelp, which when specified
would include these internal API modules.

Adjust ApiBase::makeHelpMsg() to take a boolean indicating whether internal API
modules should be shown (i.e. whether "includeinternal" was given to

Then ApiHelp::execute(), if not passed a "modules" parameter explicitly, would
check the flag and isInternalApi() to decide whether to include each module in
the output. Modules like ApiQuery that have submodules would use the new
parameter to their ::makeHelpMsg() methods to do the same.

The help output should also include indication of whether a module is internal,
much like it now does for stuff like "This module only accepts POST requests".

I'm not sure whether we should also try to adjust the output of
getAllowedParams() to omit these internal modules from the valid values for
"action", or if that would be too expensive for too little gain (if we did do
that, we'd need to do like how ApiPageSet handles generators). We certainly
should be sure not to omit the internal modules for action=paraminfo though.

(In reply to James Forrester from comment #0)
> For example, action=visualeditor is an internal API for the VisualEditor
> client to talk to its server, isn't really useful for third parties, and
> isn't remotely stable. However, because it's a built-in assumption that APIs
> are for third-party use rather than every tool being the first client of its
> API, this isn't possible. Boo.

Ideally a tool's API would be perfectly usable by third parties, not something
overly specific to the one tool's internal implementation, although that may
not always be possible. I don't know which is the case for VE's API or if it's
just that it's not yet stable.

You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list

Reply via email to