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.