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 v2v3 API requestsuests, then (b) update VisualEditor to use the RESTBase v1 API/Parsoid v3 API via VRS instead of it's crazy hybrid, then (b) update VisualEditor to use the Parsoid v2 API instead of it's crazy hybrid. We can then (c) remove "v1" API support from Parsoid.
This will take us from 4 similar-but-crazily-different APIs to only two: Parsoid v2 and RESTbase(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.
In task T100680 I propose to introduce a new Parsoid v3 API which is substantially similar to the RESTbase API,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; after which we can deprecate and remove Parsoid's v2 API and we'll be down to a single API url schemesee 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 documentconfigure Parsoid/RESTBase in mediawiki).