External callers should not need changes, or even be aware, when we replace the RESTBase "lists" endpoints with MediaWiki REST API endpoints. This means that we will need to reroute the existing RESTBase endpoints once the new MediaWiki REST API endpoints are live and publicly available.

See the associated Miro board for endpoint map.
See parent task T336693: Re-implement reading lists REST interface outside RESTBase for context and details.

More details (pasted from a Slack conversation with Hugh):

We want to replace the current RESTBase+Action API endpoints with new MediaWiki REST API endpoints, such that the mobile apps are unaware that anything has changed (in this way, it is similar to AQS 2.0, although Action API wasn't involved there). So we'll need the urls previously routed to RESTBase to instead be routed to MW REST, such that mobile apps already installed on end user devices are unaffected.

In an ideal world (from a developer's perspective), we'd modify the mobile apps to point to use normal MW REST paths, rather than the RESTBase ones. However, because we can't (or at least don't) force users to update their mobile apps, even if we did that now it'd be a long time (likely years) before few enough callers were hitting the current paths for us to retire them. Presumably the ability to run older version is important to our users for various reasons, so I'm not questioning that policy, just pointing out the technical ramifications in this case.

Reading Lists are cross-wiki and are stored on a central DB (per this bit of config in InitialiseSettings.php):

'wgReadingListsCluster' => [
	'default' => 'extension1',
],
'wgReadingListsDatabase' => [
	'default' => 'wikishared',
],

The endpoints will return the same thing no matter which wiki they actually hit. I think they're currently hitting meta, but I could be misunderstanding. My RESTBase-fu was too weak to confirm that.