One of the things I've noticed after spending some more time working with non-MediaWiki systems is that we don't always have machine-accessible information within our web pages. A fair amount of data is available in the global JS vars, but that's not trivial to read from an application that's not running in the browser.
Given the URL to some MediaWiki page -- say http://en.wikipedia.org/wiki/Foo -- we really should be able to do at least two key things:
- Get the API root URL
- Get the wiki page title for the current page (should be treated under a separate bug if details needed)
*If* we can reliably pull the JS vars, we could reconstruct the API root as wgServer + wgScriptPath + 'api' + wgScriptExtension, but honestly I wouldn't want to have to rely on that, as the data structuring isn't very standardized.
I'd recommend using the RSD "Real Simple Discovery" system, which both WordPress and StatusNet are using to expose their WordPress and Twitter API URLs:
http://cyber.law.harvard.edu/blogs/gems/tech/rsd.html
Here's an example on StatusNet... pages contain a discovery link:
<link rel="EditURI" type="application/rsd+xml" href="http://identi.ca/rsd.xml"/>
Which points to a document like this:
<?xml version="1.0" encoding="UTF-8"?>
<rsd version="1.0" xmlns="http://archipelago.phrasewise.com/rsd">
<service>
<engineName>StatusNet</engineName> <engineLink>http://status.net/</engineLink> <apis> <api name="Twitter" preferred="true" apiLink="https://identi.ca/api/" blogID=""> <settings> <docs>http://status.net/wiki/TwitterCompatibleAPI</docs> <setting name="OAuth">true</setting> </settings> </api> </apis>
</service>
</rsd>
So for MediaWiki we could output something like this:
<?xml version="1.0" encoding="UTF-8"?>
<rsd version="1.0" xmlns="http://archipelago.phrasewise.com/rsd">
<service>
<engineName>MediaWiki</engineName> <engineLink>http://mediawiki.org/</engineLink> <apis> <api name="MediaWiki" preferred="true" apiLink="http://en.wikipedia.org/w/api.php" blogID=""> <settings> <docs>http://mediawiki.org/wiki/API</docs> <!-- We could in theory expose some info like authentication --> <!-- support here, or leave it for meta=siteinfo --> <setting name="OAuth">false</setting> </settings> </api> </apis>
</service>
</rsd>
This should be pluggable, so extensions that add their own machine APIs can register themselves in there. (For instance a blogging extension could provide a WordPress-compatible API.)
Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/wiki/Foo