Page MenuHomePhabricator

Client Developer uses MediaWiki REST API
Closed, ResolvedPublic


"As a Client Developer, I want to have a RESTful CMS-level API available for each project and language, so I can provide CMS-style functionality to my end user."

For the Core REST API, we’ll use paths that look like:

/core/v<version>/<project>/<language>/<path> (If the project has multiple languages)
/core/v<version>/<project>/<path> (If the project has just one language)

There may be cases in which we will have incompatible versions of the Core REST API running on different projects. For example, if/when a version 2.x of the Core REST API is released, which isn’t backwards-compatible with version 1.x, it may roll out to Group 0, Group 1, Group 2, etc. on different schedules.


Event Timeline

eprodromou triaged this task as High priority.
eprodromou updated the task description. (Show Details)

@hnowlan I think we probably have internal routes to the mediawiki servers that would be more reasonable to use than the public ones. I don't know what those are; maybe you can figure it out?

Myself, @Clarakosi and @Pchelolo discussed this a bit and also consulted with serviceops. It would be easier for some value of easy to pass this routing off to the appservers given their existing knowledge of routing and ease of parsing, but we decided that it would be counter to the spirit of the gateway to move this logic out of the gateway. There is a first pass of this routing logic in Configuration can be seen in

In the future we will evaluate using the xDS configuration plane to offload this routing logic once it is built, as Envoy's model recommends moving routing configuration in this manner and not maintaining it as configuration. For the time being the above approach will suffice, give or take some iteration

I'm getting most of the wiki projects working correctly, but some don't. Here's the list of URLs that don't work:

I haven't checked all languages; I'll dig into them when these are fixed.

Also, I'm really surprised to see 404 errors in HTML here. It seems like the default for a failed route is to pass through to the API Portal. That's really the wrong behaviour. I've added a new ticket T260795 to track that.

Change 621581 had a related patch set uploaded (by Ppchelko; owner: Ppchelko):
[operations/deployment-charts@master] Properly set x-internal-host for domains with no lang

Change 621581 merged by jenkins-bot:
[operations/deployment-charts@master] Properly set x-internal-host for domains with no lang

Change 621585 had a related patch set uploaded (by Ppchelko; owner: Ppchelko):
[operations/deployment-charts@master] Api-gateway: fix pathing map

Change 621585 merged by jenkins-bot:
[operations/deployment-charts@master] Api-gateway: fix pathing map