https://bugzilla.wikimedia.org/show_bug.cgi?id=25648
Summary: API discovery information: add RSD link in page <head>
Product: MediaWiki
Version: unspecified
Platform: All
URL: http://en.wikipedia.org/wiki/Foo
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: API
AssignedTo: roan.katt...@gmail.com
ReportedBy: br...@pobox.com
CC: bryan.tongm...@gmail.com, s...@reedyboy.net,
vasi...@gmail.com, soxre...@gmail.com
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:
1) Get the API root URL
2) 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.)
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
