This ticket proposes to introduce the concept of component APIs [name TBD] into MediaWiki's REST framework. The goal is to provide better coesion of related entry points while avoding dependencies across teams.

The idea is that we group together sets of related REST endpoints that belong to the same business domain (or bounded context). Each such grouping forms a component API [name TBD] that has its own OpenAPI spec, is owned by a single team, and cen be versioned independently of other component APIs.

We have already been following this approach for extensions, using the convention that each extension should use a dedicated prefix for their API endpoints: E.g. CheckUser uses /checkuser/v0/, OAuth uses /oauth2/, etc. However, all the endpoints exposed by MediaWiki are exposed under the shared /v1/ prefix, even if they are entirely unrelated. And extensions are free to add endpoints under that prefix as well, making it difficult for clients to understand which endpoints they can expect to be available on every wiki.

With the new system, MediaWiki core would expose endpoints under several prefixes like /content.v2/ [or /content/v1/, TBD], so we would use /content.v2/revision/12345 instead of /v1/revision/12345. For each component API, a dedicated file would define the routes and may also contain or reference JSON schemas descibing the data structures used to interact with the entry points.Currently, all core routes are listed in a single file, coreRoutes.json, which has no support for schemas or meta-data.

More details: https://www.mediawiki.org/wiki/User:DKinzler_(WMF)/Modular_REST_API