There are too many different variants of the Parsoid API url scheme:
- Parsoid's "v1" API.
- Parsoid's "v2" API.
- Parsoid's "v3" API
- RESTbase's API, which is a hybrid of Parsoid's v1 and v2 API with some unique features of its own (ie POST parameters named "wikitext" and "bodyOnly" instead of "wt" and "body").
- The API exposed by the ParsoidVirtualRESTService in mediawiki core, which claims to be a mirror of Parsoid's "v1" API, but in fact contains features of the RESTbase API (ie, the /transform/X/to/Y/ route, and the use of a POST parameter named "wikitext").
The latter API is the one used by the Visual Editor code base, and mediawiki-core contains code to munge it into both Parsoid's *actual* v1 API and the RESTbase API.
In this task I plan to (a) update ParsoidVirtualRESTService to always issue v3 API requests, then (b) update VisualEditor to use the RESTBase v1 API/Parsoid v3 API via VRS instead of it's crazy hybrid, (c) update RESTBase to issue v3 API requests, and (d) update Flow to use the RESTBase v1/Parsoid v3 API via VRS. We can then (e) remove "v1" and "v2" API support from Parsoid.
This will take us from 4 similar-but-crazily-different APIs to only one(ish): RESTBase v1 (and Parsoid v3, which was explicitly designed to be as similar to RESTBase v1 as possible; see T100680).
This will remove a bunch of hairy URL translation code from Parsoid, RESTbase, and mediawiki-core, as well as concentrating our efforts on documenting a single API (and single way to configure Parsoid/RESTBase in mediawiki).