Page MenuHomePhabricator

Mediawiki API - How can Clients stay in synch with core API changes?
Open, Needs TriagePublic


To make the Mediawiki-JAPI generated java code from Schema approach feasible the MediaWiki API could be improved:

  • an XSD schema or replacement for it (e.g. action=paraminfo)
  • a list of possible error messages in computer readable format
  • API specific test cases

Related Objects

Event Timeline

Seppl2013 raised the priority of this task from to Needs Triage.
Seppl2013 updated the task description. (Show Details)
Seppl2013 subscribed.

When was created the bug T16025 was discussed again because using an XSD schema
was the most feasible approach to get generated Java code.
See and

The idea was to have at least the same functionality as MER_C's one class Java implementation

The intention was also to get the new Mediawiki-Japi reviewed as other Mediawiki Client APIs had already been reviewed. It seems that there was only one entry for Java at the time. MER-C's solution was not on the list (?)

For input, action=paraminfo is the machine-readable specification. Output is very unlikely to happen; we used to have poorly-maintained lists of possible errors and undocumented and poorly-maintained specification of output, but it was removed in Gerrit change 152760 because it's effectively impossible to keep up to date when new errors can be introduced in underlying core or extension code and so on.

Test cases are a very intriguing idea, I'd like to see something where there's a list of "this input => this output" that could be used by MediaWiki's phpunit tests as well as client libraries.

How is evolving of the API done - how can Client Library authors keep up to date with changes in the API?
A schema could be an approach. But as it where a schema would have to be kept up-todate with source code changes in the core and in extensions which is virtually impossible.

Should there be recommendations for Client APIs?
E.g. naming

  • should there be standard naming for API functions like login(), getPageContent(), getSiteinfo() ...
  • should there be efficiency recommendations e.g. when you would like to find out a new state of a couple of hundred pages the recommend way is to keep a cache of pageContents hashed by revision id and then do just two calls:
    • get revisionids for all pages that are in the cache
    • get pages where revision id has changed

Yuris ideas are to create a thin layer that will have the most basic functions in collaboration with API developers

  • login
  • api call
  • querycontinuation
  • checks for errors
  • checks for warnings

see also

Seppl2013 renamed this task from Mediawiki API 2015 Lyon Hackathon ideas to Mediawiki API - How can Clients stay in synch with core API changes?.May 25 2015, 9:53 AM

Proposed action items:
Make separation of

  • Implementation
  • Declaration (e.g. interface)
  • Tests

Encourage evaluation of client libraries comparable to way of evalution

A good approach might be e.g. evaluation sessions at in-persons meetings like Hackathons

StjnVMF renamed this task from Mediawiki API - How can Clients stay in synch with core API changes? to unban reguyla.May 18 2018, 5:21 PM
StjnVMF updated the task description. (Show Details)
StjnVMF removed subscribers: intracer, StudiesWorld, Yurik and 4 others.
Dzahn renamed this task from unban reguyla to Mediawiki API - How can Clients stay in synch with core API changes?.May 18 2018, 5:33 PM
Dzahn updated the task description. (Show Details)