Talk: â€œMediaWiki APIâ€ by Yuri Astrakhan
Summary: â€œIt’s all about the data, stupid!â€
Yurikbot: More than 3 million edits.
Does not use the HTML rendering code.
Example of this; The navigation pop ups extension â€“ this uses the API (because it is faster).
We have login
Can query existing data
Multiple output formats.
Change data (this is currently in development by the Spanish Vodafone folks, among others)
API is very modular â€“ can add things, and they will just plug in.
Can get some of the following:
Lists (e.g. list of backlinks to a page)
Can get multiple types of information all in one query
Conveniences to avoid gotchas â€“ e.g. normalisation, resolving redirects, etc.
(gave some demos of these on the live Wikipedia).
Tries to be very quick â€“ only does the work that you ask it for.
Gave API performance figures: API gets 2% of Wikimedia site hits. Yet uses 0.1% of CPU load. I.e. API is 20 times more efficient than the main UI. However at the moment is a read-only API, so would expected better performance that the main UI (which also has to do writes).
Most of the hits are coming from the Open Search module currently.
Future: Want to add unit tests for the API (Note from me: it’s coming, but don’t hold your breath!).
Asked API users to use GZIP compression when calling it â€“ added recently to PyWiki â€“ this saves lots of bandwidth.
In the Q&A time, I asked the Vodafone folks about the API write capacity they’re working on, and very roughly when they thought it might be ready: Their estimate: Should be ready around Christmas (i.e. 4.5 months). They want it for their mobile phone customers, who want to be able to modify the Wikipedia, as well as view it on their mobile phones.
Demo time: Showed some examples of some API code (e.g. added a simple module, showed how to add new supported formats to the API).