Some potential subtasks:

• make a public project page (blast from the past!)
• make some kind of outreach strategy (make announcement, tell interested people to work with us on Phabricator, have some idea on what the checkpoints are at which we want to gather more feedback)
• decide on the entry point
• extension interface (the handler interface is a big part of that, but also, what do you put in extension.json? How would the equivalent of, say, the APIQuerySiteInfoGeneralInfo hook look in a REST framework?)
• logging and monitoring
• testability (writing unit tests for the action API is not fun; for the new API we should design for ease of API module unit tests from day one)
• developer and user documentation
• do we want to investigate async PHP (a ReactPHP-like API endpoint) at some point?
• do we want to provide a client library in MediaWiki (something like mw.api)?

Btw do we want to split this into a generic epic about the planned MediaWiki REST API, and an MVP specifically for Parsoid? It would make it easier to see which tasks are blockers for the Parsoid project.

Am I right in assuming the idea is that integrating Parsoid functionality into the MW API is not enough, we need to maintain compatibility with existing Parsoid clients and therefore MW Core needs to add support for REST APIs?