Define a REST module with the name "content.v1" (see T368461), so clients that are currently using the parsoid endpoints exposed by RESTbase can be migrated (see T334238). The endpoints that will be exposed under content.v1 already exist under the global v1 prefix. They will be accessible from both locations from now. We expect to deprecate access using the global v1 prefix in the future, and make the old paths redirect to the new paths.
== Requirements ==
The new endpoints will be exposed under:
* /api/content.v1/page/{title}
* /api/content.v1/page/{title}/with_html
* /api/content.v1/page/{title}/html
* /api/content.v1/page/{title}/bare
* /api/content.v1/revision/{id}
* /api/content.v1/revision/{id}/with_html
* /api/content.v1/revision/{id}/html
* /api/content.v1/revision/{id}/bare
We also support POST and PUT for creating/updating pages:
* POST /api/content.v1/page
* PUT /api/content.v1/page/{title}
The new paths for these endpoints can be defiend by creating a module definition file (T362480).
The relevant Mocha tests should be updated to run for both prefixes.
For the work needed to make the /api/ prefix usable for MediaWiki REST endpoints see (T364400). This is out of scope for this task.
== Context ==
We are planning to deprecate the Parsoid endpoints that are currently exposed through RESTbase (T334238). Clients should use the equivalent core endpoints instead. In order to support this, we want to make the URLs of the core endpoints [[https://docs.google.com/presentation/d/173WciDCIcdBvMFnq1scVqCG02Hk_wtiya9zYFiqDRQU|more future proof]].
The old parsoid endpoints on RESTbase are:
* /api/rest_v1/page/title/{title}
* /api/rest_v1/page/title/{title}/{revision}
* /api/rest_v1/page/html/{title}
* /api/rest_v1/page/html/{title}/{revision}
These endpoints are functionally equivalent but structurally different. The endpoints for retrieving HTML without a JSON wrapper are nearly exactly the same, they only differ in the handling of wiki redirects. These two are similar enough to their new equivalents that we will start redirecting from them to the new ones once most of the client traffic has migrated:
* /api/rest_v1/page/html/{title} -> /api/content.v1/page/{title}/html
* /api/rest_v1/page/html/{title}/{revision} -> /api/content.v1/revision/{revision}/html