When http://mediawiki-japi.bitplan.com was created the bug T16025 was discussed again because using an XSD schema
was the most feasible approach to get generated Java code.
See
http://mediawiki-japi.bitplan.com/mediawiki-japi/index.php/Jaxbgenerator and
https://github.com/WolfgangFahl/Mediawiki-Japi

The idea was to have at least the same functionality as MER_C's one class Java implementation http://github.com/MER-C/wiki-java

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.

Also you mentioned the reviews at https://www.mediawiki.org/wiki/API:Client_code/Evaluations#Java that were done by @Fhocutt.

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
e.g.

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

see also

• https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap
• https://www.mediawiki.org/wiki/API/Architecture_work/Planning

Proposed action items:
Make separation of

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

possible
Encourage evaluation of client libraries comparable to https://www.mediawiki.org/wiki/API:Client_code/Evaluations/Pywikibot way of evalution

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