Flow/Architecture/API


 * See also: Extension:Flow/API
 * We'll hold a workshop to Update bots to handle Flow boards at the MediaWiki Developer Summit 2015

Flow has an extensive API that's heavily exercised by one client – the JavaScript on Flow boards – as you can see if you interact with a Flow board with JavaScript enabled and watch the API requests in your browser's developer tools > Network tab.

Most URL (HTTP ) and form (HTTP  ) actions are mirrored in the Flow API.

General comments
Flow pages are not wiki pages. Consequently, many typical wiki page API requests will not work, such as.
 * they use a different ContentModel
 * they store revisioned content differently

The Flow team has considered mimicking the page API, but there's no one right answer to where to modify. For example should a page edit update the board header, or should it create a new topic?

action=query

 * returns  key if Flow is enabled on a page, see . No parameters.  As of September 2014 this returns enabled for Flow Topic:UUID pages as well as Flow boards.
 * You can also check if the content model of a page is . As of November 2014 both Flow boards and individual Topic:UUID pages have this content model, .)
 * You can also check if the content model of a page is . As of November 2014 both Flow boards and individual Topic:UUID pages have this content model, .)


 * obsolete
 * any  is passed on to WorkflowLoader, which will create multiple block objects and pass the flowaction onto them. flowaction can be view, header-view, and topic-summary-view. Each of these they take different parameters.

action=flow API
The read and write API consists of submodules of, you can see them on the API page  [//www.mediawiki.org/w/api.php www.mediawiki.org/w/api.php].

Unfortunately Special:ApiSandbox is not aware of submodules, so you can't drive this action=flow API from it.

Read API
JS in the browser calls the API to etc.
 * paginate in the next 10 topics
 * request topics in different sort orders
 * get the wikitext when editing existing posts

with  topiclist-view, post-view, topic-view, header-view, topic-summary-view, etc.

Write API
You need to decide if your goal is to reply to an existing topic, create a new topic, add something to the Flow board header, or some other interaction.

Sketch of replying
In a reply you're replying to a particular post in a workflow (a topic). Flow objects are identified by UUIDs see Flow/Architecture.

To reply to a topic action=flow submodule=reply format=json repreplyTo=050fed5dc6bd5085237590b11c2fa805 repcontent=My reply, with wikitext.
 * you'll need a token. Flow recently switched to using the regular 'edit' token for most operations, so you can use  to get the editing token if it hasn't been cached yet in the session. it's cached.
 * Issue a  API request with , identifying the topic workflow. The parameters for a reply include the topic and the post.

render=true token=43a71deb105e7c0be7e8eeab4bdff4f7+\ workflow=050f698e3f6e5624fa1590b11c27932f
 * Set  if you want the server to respond with the "fully-decorated" HTML to interact with the new post (preview buttons, actions, etc.).
 * UUID format will soon change to be more compact, using 88-bit represented as alphadecimal.
 * Obviously you get the topic and post to respond by making API queries, rather than hardcoding these numbers.

Note that a wiki may store Flow content with  'html' or 'wikitext', but in any edit submission you must submit wikitext.

If successful, the server responds with the  of the new post, and the HTML to insert into the DOM.

Note this API request doesn't name the page on which the topic appears. Users interact with topics on a Flow board with a wiki page name, but a topic might (eventually) appear on multiple pages, e.g. a user's "subscription feed".

On WMF wikis, Flow stores post content as HTML with embedded Parsoid markup so that the original wikitext can be reconstituted for editing. This will not be the case on all wikis, others might store as wikitext.

Block requests
When you make a "Block" API request such as new-topic, the API normally returns a  containing updated information about the 10 topics on the board, including their HTML. This allows the Flow board to redisplay the board contents, but it's a lot of data.

If you are just trying to add at topic and you're not interested in the board contents, you should pass the flag  (180588)

Flow returns the metadata in a top-level  key in the API response. For consistency the information about the new content is returned as post-revision-id, topic-revision-id, header-revision-id, etc.

Editing the board header
If you want to update the Flow board header, it's similar
 * make a GET request  to get the current contents. This will return a   including a UUID of the most recent version of the header in , and its contents in.
 * make a POST request, . Set   to the revision returned by the GET request and set   to your updated wikitext.

The update may fail with  if someone else updated this board's header between the two requests; if so the return has a   giving the new latest revision, so you can retry with that

flow-parsoid-utils
Requests conversion between html and wikitext. If the wiki isn't running Parsoid, conversions from html to wikitext will fail.

This is meant to be an "internal" API for Flow to be able to communicate with Parsoid client-side. If you want to convert wikitext<-->html using Parsoid, you should use its own API.

Future API changes
Eventually move to a service-oriented architecture. Might look like proposed Content API.

External clients should be able to use OAuth to authorize bots to make Flow changes on their behalf. This should work for the most common actions, such as posting a new topic and replying. Anything requiring the Flow rights (e.g. flow-hide, flow-lock, flow-delete, flow-edit-post) will likely be forbidden via OAuth until it's properly exposed,.

Other API issues

 * Should existing API calls to edit to a page "just work" on a Flow-enabled "page"?
 * Probably not since the caller really has to decide whether the change is to the board header or a new topic.
 * What should happen to regular page API requests made to a Flow-enabled page,.


 * post editing rights for bots.
 * ordinarily only the poster can edit his or her reply, unlike a regular wiki page.

Missing APIs?

 * Do people need an API to enumerate pages / namespaces that are using Flow?
 * currently, would just return values of  and  . When a Flow board becomes a content type, the former could be replaced by a query for pages with the   contentmodel, though there does not seem to be a generator for this.


 * API to generate a link to a post/topic/board given a UUID
 * Options: wiki link or URL; show standalone topic or show Flow board paginated to topic
 * must caller be aware of whether the UUID is a workflow (topic) or post or header?
 * note redirector functionality (e.g. Special:Flow/workflow/ru0aehx63b43khdl and Special:Flow/post/ru22c9f18csotjs7) is in release 1.24wmf4.

Use cases

 * please update, especially with links to bots (Flow/Bots)

Extension:MassMessage
Detects whether it is interacting with a Flow board by checking ; if so then adds its message to the Flow board by making an API request with   (see patch).

Bots patrolling new content

 * ? have to watch for changes
 * ask for new and changed topics and posts

Bots making edits

 * Adding topics (and/or posts)
 * Correcting old posts
 * Modifying talkpage headers
 * Checking if the bot has already made a particular post to a particular page
 * Often implemented by a subject line check, or a check for a particular.
 * Ability for users to remove or otherwise signal that the bot-raised issue is taken care of, so the bot can know to repost it if it recurs.
 * Opting out of bot messages (eg. Enwiki's template:nobots).

Tools showing count of edits

 * Contributions with Flow at some wiki aren't included in X!'s Edit Counter for that wiki, maybe because Flow is in a separate database. See, though this is more a DB tool than a bot.

Finding links
In bug 57512 comment#22 Brad Jorsch commented:


 * And there are also a number of API modules that query the existing links tables; there should at least be some way to (1) identify that a page is Flow and (2) search these flow-specific links tables to find the actual "thing(s)" doing the linking in the particular page.

Flow/Architecture sketches the implementation.

Non-issues
No need to check for unsigned edits, replies are known.