Last modified: 2014-04-19 00:46:14 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T50483, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 48483 - Expose a public web API end point in the MediaWiki API
Expose a public web API end point in the MediaWiki API
Status: ASSIGNED
Product: Parsoid
Classification: Unclassified
Web API (Other open bugs)
unspecified
All All
: Normal normal
: ---
Assigned To: Gabriel Wicke
:
Depends on:
Blocks: 52936
  Show dependency treegraph
 
Reported: 2013-05-15 00:41 UTC by Gabriel Wicke
Modified: 2014-04-19 00:46 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Gabriel Wicke 2013-05-15 00:41:08 UTC
We need a public API end point integrating with the general MediaWiki API that provides at least the following functionality:

* HTML DOM retrieval per page and revision. Basically the /en/Foo?oldid=<n> end point.
* HTML DOM expansion: POST a DOM (or fragment), return re-expanded DOM
* HTML DOM saving: POST a modified DOM and a summary, and save it as a new revision.

As long as we are using Wikitext as our storage format, saving requires a conversion to HTML and a separate save step. The individual steps should *internally* be exposed to other users including the VisualEditor extension. There is probably no need to expose the HTML2WT conversion. We should instead aim to provide an HTML-only public interface.

The integration should use an URL schema that makes it easy to map some or all of the functionality to a stand-alone (non-PHP) backend to avoid PHP startup costs in the future.
Comment 1 James Forrester 2013-05-16 01:52:21 UTC
(In reply to comment #0)
> * HTML DOM saving: POST a modified DOM and a summary, and save it as a new
> revision.

Just to clarify, we don't need this for June/July (we're doing it in VisualEditor currently) - though it's a nice-to-have. :-)

The real focus for us is the HTML DOM expansion, which we will want ASAP for templates and other generated content blocks.
Comment 2 Kelson [Emmanuel Engelhart] 2013-07-10 20:41:21 UTC
Building prod. tools based on Parsoid output (for example to produce offline snasphots) needs this MW API. http://parsoid.wmflabs.org/ can only be a temporary solution...
Comment 3 Gabriel Wicke 2013-08-08 01:59:54 UTC
Bumped the prority. We should get to this after Wikimania.
Comment 4 Gabriel Wicke 2013-08-23 16:03:11 UTC
Marco and I are taking this on.
Comment 5 Gabriel Wicke 2013-09-03 22:40:26 UTC
The PHP parser output is exposed through action=parse:

http://en.wikipedia.org/w/api.php?action=parse&redirects&prop=text%7Cdisplaytitle&format=xml&page=FOOBAR
Comment 6 Gabriel Wicke 2013-11-12 21:58:59 UTC
Once https://gerrit.wikimedia.org/r/#/c/93527/ is merged we'll provide interim access to our internal Parsoid cluster through front-end caches at http://parsoidcache.svc.eqiad.wikimedia.org/. This implements our internal https://www.mediawiki.org/wiki/Parsoid#The_Parsoid_web_API. In the longer term it will be replaced with a more general MediaWiki content API that we are still working on.
Comment 7 Gabriel Wicke 2013-12-03 22:16:45 UTC
Lowering the priority as this is now live:

http://parsoid-lb.eqiad.wikimedia.org/
https://parsoid-prod.wmflabs.org/  (also supports spdy)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links