Defining the MW_API constant (which is basically a way to say that we have entered the application via api.php) triggers various API-related behaviors:
- (needed) disables inserting a title parameter into $_GET (WebRequest::interpolateTitle)
- (?) allows use of the Promise-Non-Write-API-Action header (WebStart.php)
- (needed with modifications) switches to simple error output (minimal HTML + header instead of full wiki page) (MWExceptionRenderer::output, MWException::report, ErrorPageError::report)
- (needed) only allow certain authentication methods (bot passwords, centralauthtoken, OAuth) via the API (BotPasswordSessionProvider::provideSessionInfo, CentralAuthTokenSessionProvider::provideSessionInfo, MWOAuthSessionProvider::provideSessionInfo)
- (probably needed) skips CentralAuth edge login, marks session to do it on the next non-API request (CentralAuthHooks::doCentralLoginRedirect)
- (needed if we want a REST login API, harmless otherwise) suppress some messaging / special handling during certain logins that would not make sense / would be hard to implement in the API (CentralAuthPrimaryAuthenticationProvider::beginPrimaryAuthentication, ConfirmAccountPreAuthenticationProvider::testForAccountCreation)
- (irrelevant) some kinda action API specific error handling hack in CirrusSearch (CirrusSearch::prefixSearch, CirrusSearch\Hooks::onSearchGetNearMatch)
- (needed) marking the action as originating from the API in various logs/stats (CirrusSearch\Util::getExecutionContext, AuthManagerStatsdHandler::getEntryPoint, WikimediaEventsHooks::onPageContentSaveComplete, CampaignsSecondaryAuthenticationProvider::beginSecondaryAccountCreation)
- (unwanted) hacky way of identifying (along with looking at $_GET['action']) when we are in a specific API module (WikimediaEventsHooks::onUserSaveOptions)
- (needed) identifying human actions for analytics or similar purposes (WikimediaEventsHooks::onRecentChangeSaveCrossWikiUpload, WikimediaEventsHooks::onRecentChangeSaveEditCampaign, WikipediaAppCounter::isWikipediaAppMwApiRequest)
- (never made sense in the first place) do not display captcha when functionality is accessed via the API (SimpleCaptcha::confirmEmailUser)
- (probably needed) dirty parser hacks, see T111346#1642128 (HtmlPageLinkRendererBeginHookHandler::doHtmlPageLinkRendererBegin)
The REST API will also need many of those, but probably not all, and maybe not always exactly in the same way (e.g. it triggers bare-HTML fatal error rendering; for the REST API we might want to make it plaintext instead.) That needs to be handled somehow, maybe by splitting it into MW_ACTION_API and MW_REST_API.