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

Reply via email to