Apps and API-driven skins will need access to existing MediaWiki functionality like special pages. Currently, there is no clean API that

• covers both wiki content and special pages,
• allows interaction with special pages the same way regular, fully skinned access do, and finally
• provides page component metadata to allow loading of appropriate RL modules, and more generally composition (see T105845).

Implementation options

1. API:
   1. Extend action=render to cover special pages, as proposed in T106894.
   2. Extend action=parse to cover special pages.
   3. Create a new API entry point altogether.
2. Skin: Create a "null" skin that only returns the content area & metadata, and select it with a header.

Discussion

• URL compatibility: The "null" skin has the advantage of interfering least with current interaction patterns by using the same URL layout as regular page views. Forms posting back to a special page should work as-is, although we'd need to be careful to make sure that the skin selection header is consistently applied. Preserving URL compatibility in API end points would be difficult.
• Caching: Compared to query strings, the Skin tends to provide more deterministic URLs, which is good for caching. We'd need to set up a vary on the skin header. Purging would continue to work as-is.
• Discoverability: The API options shine here by integrating with existing API documentation.
• Alternative skin selection methods:
  • A cookie is easy to set, but slightly harder to work with in caches (vary) and other proxies. It is also reliably added to redirected requests.
  • A custom header is easy to set in proxies like ServiceWorkers or services, and has good vary support. On redirect, custom headers might be dropped.
  • Adding a query string requires URL parsing, and might be dropped on redirect.

Tentative conclusion

The "null" skin option looks like the most attractive option overall. For the skin selection, a custom header seems to be slightly easier to use than a cookie.