Create MediaWiki REST API handlers (and associated code) to (eventually) replace the existing RESTBase "lists" endpoints and the existing Reading Lists extension Action API endpoints.
The new endpoints should be call-compatible with the existing RESTBase endpoints. In all but one case, the existing RESTBase endpoints all forward the call to Action API endpoints, so much of the work will be created MediaWiki REST API endpoints that are call-compatible with the RESTBase endpoints, but which provide the functionality from the Action API endpoints. (The endpoint that does not forward the call is /lists/{id}/entries. This one does make an Action API call, but also includes logic in the RESTBase code that will need to be duplicated.)
It may be necessary to modify/refined the MediaWiki REST API infrastructure in various ways (for example, T305973: JsonBodyValidator does not validate the parameter types) If any such work is significant, we can create separate subtasks.
Individual endpoint subtasks:
- T351145: Reading List REST Interface: POST lists/setup endpoint
- T351146: Reading List REST Interface: POST lists/teardown endpoint
- T351147: Reading List REST Interface: GET lists endpoint
- T351148: Reading List REST Interface: GET lists/pages endpoint
- T351149: Reading List REST Interface: GET lists/changes/since endpoint
- T351150: Reading List REST Interface: POST lists endpoint
- T351151: Reading List REST Interface: POST lists/batch endpoint
- T351152: Reading List REST Interface: PUT lists endpoint
- T351153: Reading List REST Interface: DELETE lists endpoint
- T351154: Reading List REST Interface: GET lists/{id}/entries endpoint
- T351155: Reading List REST Interface: POST lists/{id}/entries endpoint
- T351156: Reading List REST Interface: POST lists/{id}/entries/batch endpoint
- T351157: Reading List REST Interface: DELETE lists/{id}/entries endpoint
All handlers should include tests, any appropriate monitoring/logging support, etc.
At the RESTBase level, response header handling in the existing code is provided by mediawiki_auth_filter.js. This filter (if the author of this task is reading it correctly...) includes any 'cookie', 'x-forwarded-for', or 'x-client-ip' headers provided by the Action API endpoint. This means that we need to match the header handling provided by Action API for (only) those headers.
Additional headers may be provided by other layers of the infrastructure (varnish, etc). We should confirm header handling before considering the endpoints complete.
Callers are currently providing csrf tokens as a query parameter. For example:
curl -X 'POST' \
'https://en.wikipedia.org/api/rest_v1/data/lists/?csrf_token=f63c343876da566045e6b59c4532450559c828d3%2B%5C' \
-H 'accept: application/json; charset=utf-8' \
-H 'Content-Type: */*' \
-d '{
"name": "Planets",
"description": "Planets of the Solar System"
}'The token is then included in the forwarded Action API request as a query parameter named "token", which is the normal way the Action API receives tokens. The MediaWiki REST API, on the other hand, includes support for csrf tokens sent as a "token" parameter in the request body. This support is implemented via the TokenAwareHandlerTrait. To avoid forcing callers to make changes, the Reading Lists handlers will need to be able to receive tokens via a "csrf_token" query parameter. TokenAwareTrait won't help with this directly, but code within it might be useful for inspiration.
See the associated Miro board for endpoint map.
See parent task T336693: Re-implement reading lists REST interface outside RESTbase for context and details.