Proposal:RPC-based facebook-esque API

Status (see valid statuses)

---

The status of this proposal is:
Request for Discussion / Sign-Ups

Strategic Priorities

Every proposal should be tied to one of the strategic priorities below.

Edit this page to help identify the priorities related to this proposal!

1. Achieve continued growth in readership
2. Focus on quality content
3. Increase Participation
4. Stabilize and improve the infrastructure
5. Encourage Innovation

Share this:

Summary

Access to Wikipedia is force-channelled through an HTTP interface that is subject to change, and requires continuous HTTP access during viewing and editing of pages. Writing a fully-functional alternative and stable API, along the lines of facebook's API and opensocial, allows developers to create fully functional alternative user interfaces that are more appropriate to particular audiences or devices, and with capabilities that the Wikipedia Web Team need not get involved in (or otherwise restrict).

(Note: the existence of http://www.mediawiki.org/wiki/API:Changing_wiki_content has been observed, since the creation of this proposal. Please therefore adapt the proposal to mean "Please extend the mediawiki API in order to meet the criteria as specified in this proposal")

Proposal

• Add a distributed JSONRPC, REST, XMLRPC or SOAP front-end to the wikipedia database.
• Provide an application (as an example / reference implementation) which can be a stand-alone version of the wikipedia front-end

Note: The API should be sufficiently comprehensive such that the entire current wikipedia HTTP-based interface can be replicated, in its entirety, by any developer, in any programming language of their choice.

Note: The API should be sufficiently comprehensive such that it could even be utilised by peer-to-peer services, to create distributed wikipedia nodes for backup purposes, cacheing and much more. see Proposal:Distributed_Wikipedia and others in http://strategy.wikimedia.org/wiki/Category:Proposals_for_distributed_infrastracture

Motivation

• In order for arbitrary developers to develop enhancements and augmented user-interfaces, the present situation requires that the developer write php code (which they may despise or otherwise decide "not a snowball in hell's chance i'm gonna contribute to _that_"). The wikipedia web team cannot just randomly provide arbitrary developers with the rights to run arbitrary code submissions on the main wikipedia web servers, and thus a massive burden is placed on the wikipedia team to carefully review submissions (actually what happens is: nobody bothers to submit anything innovative, at all, because it's too much hassle). By providing a full interaction API, arbitrary developers may create their own user-interfaces *without* the wikipedia web team having to get involved.
• The creation of a full interaction API (a la facebook API) extends the reach of wikipedia beyond the limitations of its current web-only interface.
  • example: an affordable embedded system (or a mobile phone application) which can be made available in third world countries may simply not have the resources to run javascript, and a simpler interface can be designed which stores edits inside the device.
  • example: the OLPC or other team may decide that the branding of the wikipedia web site is not something that they want to present learning material through. however, they still want the wikipedia pages and they still want users and students to be able to contribute. by redesigning the interface to suit the OLPC or other project, the users / students are not cut off from "wikipedia the resource".
  • example: someone _will_ end up creating an iphone app. without the wikipedia team having to customise the web front-end presentation of wikipedia.org / detection of the HTTP user-agent string etc. less work for the wikipedia team.
  • example: an alternative application with the full functionality of the current wikipedia.org HTTP interface but with special consideration for people with learning difficulties or physical disabilities. less work for the wikipedia team, and the developers of the application are empowered, through the API, to provide their users with the exact same powerful contribution rights as anyone else who uses the current wikipedia.org HTTP interface.

Appendix: Rough Outline of GUI-to-back-end RPC-based API

this API is near-trivial to design and implement. readers are advised to look up the "facebook developer API" as this API and its implementation are the "guiding light" behind this front-end API (except that the implementation will be entirely free software licensed, unlike the facebook API implementation).

please note: all functions in this API are considered to be *synchronous*.

examples of required functions in the front-end RPC-based API

• create new user function.
• login function.
• edit profile function.
• for convenience: get fully-rendered HTML wikipedia page (as data, not via HTTP GET)
• get raw un-rendered HTML wikipedia page (as data).
• get list of file attachments (unique names) associated with page
• get specific attachment (by unique name) associated with page (as data, not via HTTP GET)
• search for list of pages (title search, full search etc).
• show edits / changes
• revert / undo specific change
• submit edit of page
• submit file for upload (associated with page)

etc.

in other words, EXACT duplication, verbatim, of every piece of functionality which the current HTTP wikipedia.org interface provides, including some functions that are currently done as pure "HTTP GET" - except done as a JSONRPC or other service. easy.

Note: the similarity between the rough outline here and that of http://www.mediawiki.org/wiki/API:Changing_wiki_content has been noted. In reviewing the mediawiki API, it would appear that, at a first glance, the only functions missing are those related to alternative authentication systems, and the only other question is: why the hell did the designers of mediawiki's API not pick something that's a standard, such as JSONRPC??

Community Discussion

Do you have a thought about this proposal? A suggestion? Discuss this proposal by going to Proposal talk:RPC-based facebook-esque API.

Want to work on this proposal?

1. .. Sign your name here!