iOS teams should verify and give signoff, then will require a follow-up change to implement in the Apps

Rough outline for testing and integrating with the new endpoints:

The endpoints have been basically rebuilt in the new MW REST system to match one-to-one with the old RESTBase system.
Here is a list of all the new endpoints.

So for example, the previous route https://meta.wikimedia.org/api/rest_v1/data/lists/ would now become https://meta.wikimedia.org/w/rest.php/readinglists/v0/lists/. All the new endpoints are already live in production, and should produce the exact same results as the old endpoints. They are intended to be a drop-in replacement for the old routes, accepting the same request parameters, except for some differences in error formatting. So:

• Take the current version of the app and drop in the new endpoint URLs in place of the old ones (without changing anything else), and see if everything works as expected. This is to simulate an "older" version of the app communicating with the new endpoints, to which the old endpoints will soon redirect.
• Note that the format of errors returned by MW REST is different from RESTBase, but these new endpoints have been set up to output both error formats in the same response, so it should be compatible with older clients. (outputting both error styles will be temporary, and eventually only the new-style errors will be returned) For a comparison of the two error formats, see this comment: T357478#9573094
  • Basically, the old system returns errors with a title and detail parameters, and the new system returns errorKey and messageTranslations parameters.
• If everything works smoothly, great -- If you find something that doesn't work as expected, please document it here.
• Finally, in your "new" version of the app, only the new endpoint URLs should be used, and only the new error format should be expected.

Confirmed iOS compatibility looks good. Endpoint was changed in this commit and regression testing occurred.

Successful endpoint tests:
POST https://en.wikipedia.org/w/rest.php/readinglists/v0/lists/setup?csrf_token={nnnn}
POST https://en.wikipedia.org/w/rest.php/readinglists/v0/lists/teardown?csrf_token={nnnn}

GET https://en.wikipedia.org/w/rest.php/readinglists/v0/lists/
GET https://en.wikipedia.org/w/rest.php/readinglists/v0/lists/{listid}/entries/
GET https://en.wikipedia.org/w/rest.php/readinglists/v0/lists/changes/since/

DELETE https://en.wikipedia.org/w/rest.php/readinglists/v0/lists/{listid}/entries/{entryid}?csrf_token={nnnn}
DELETE https://en.wikipedia.org/w/rest.php/readinglists/v0/lists/{listid}?csrf_token={nnnn}

PUT https://en.wikipedia.org/w/rest.php/readinglists/v0/lists/{listid}?csrf_token={nnnn}

POST https://en.wikipedia.org/w/rest.php/readinglists/v0/lists/{listid}/entries/batch?csrf_token={nnnn}
POST https://en.wikipedia.org/w/rest.php/readinglists/v0/lists/batch?csrf_token={nnnn}
POST https://en.wikipedia.org/w/rest.php/readinglists/v0/lists/?csrf_token={nnnn}

Confirmed error handling works as before:
for GET lists/changes/since/ - readinglists-db-error-not-set-up
for POST lists/?csrf_token={nnnnn} - readinglists-db-error-list-limit
for PUT lists/{{listid}} - readinglists-db-error-list-deleted

Notable things:

So for example, the previous route https://meta.wikimedia.org/api/rest_v1/data/lists/ would now become https://meta.wikimedia.org/w/rest.php/readinglists/v0/lists/

iOS hardcodes an en.wikipedia.org host no matter what language the user has set up in their app languages. I assume this is ok, it worked fine in my testing.

Basically, the old system returns errors with a title and detail parameters, and the new system returns errorKey and messageTranslations parameters.

From what I gather iOS only used the title error value, so I can switch it over to only using the errorKey parameter. It looks like iOS defines its own native detail strings based on that key code. My plan is to not use messageTranslations when we update the app to keep changes limited.

Finally, in your "new" version of the app, only the new endpoint URLs should be used, and only the new error format should be expected.

This work is completed in branch reading-list-api-changes.