Output:2.1: Difference between revisions
From atwg
(Created page with "{{Output |Description=REST API for MediaWiki |Parent Outcome=Outcome:2 }}") |
m (Ccicalese moved page Output:010 to Output 2.1 without leaving a redirect) |
||
(5 intermediate revisions by the same user not shown) | |||
Line 2: | Line 2: | ||
|Description=REST API for MediaWiki | |Description=REST API for MediaWiki | ||
|Parent Outcome=Outcome:2 | |Parent Outcome=Outcome:2 | ||
|Primary Team=API | |||
|Collaborating Teams=MediaWiki Platform, Audiences Product and Design, Services, Readers Web, Reading Infrastructure | |||
|Archived=No | |||
}} | }} |
Latest revision as of 08:54, 20 February 2018
Output | REST API for MediaWiki |
---|---|
Parent Outcome | More of the full functionality of MediaWiki can be delivered across all interfaces, devices, and form factors while maintaining usability, accessibility, and internationalization standards |
Primary Team | API |
Collaborating Teams | MediaWiki Platform, Audiences Product and Design, Services, Readers Web, Reading Infrastructure |
Task | Description | Depends On Tasks | Type | Associated Outputs | Primary Team | Collaborating Teams | Start Year | Duration | Risks | Contingencies | Benefits | Assumptions | Implications | Notes |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Make REST Routing possible in MediaWiki | Enable PHP based routing of URLs in MediaWiki to enable REST along with an easy way for developers to specify caching and purging semantics. The routing should be fast and preferably not require all of MediaWiki to be loaded in order to start. Routing patterns should be standard both in and outside of MW. This should be transparent to clients. | Write Architecture Spec | Development | Output 2.1 | MediaWiki Platform | Services, Reading Infrastructure | 0 | 6 | Routing for external services should be handled outside of MediaWiki (Varnish). The MW routing should be done using a service runner that can be run separately from MW for WMF use, but could be run in the same process for small installs. Where a service lives, node, MW, or elsewhere should be transparent to clients. We should then figure out any necessary routing, mapping, proxying, etc without the clients needing to worry about this. This means we have an agreed upon REST url pattern that spans all services and routers. For MW APIs, thsse should be routed from Varnish to MW via some sort of configuration. | |||||
Identify features that the REST API needs to support | Perform Product and IA analysis to identify which workflows and features to build REST APIs (and PHP APIs) to prioritize first as needed we work to expose more of the full functionality of MediaWiki APIs. | Research | Output 2.1 | Audiences Product and Design | Readers Web, Reading Infrastructure, Services, MediaWiki Platform | 0 | ||||||||
Design MediaWiki REST API | Design and prototype a REST API that would enable the full functionality of the desktop web experience in MediaWiki Core (and "critical" extensions?) with cacheability and consistent parameters, property names and objects. Note that this highly depends on the overall design of information flow (see Output 1.1) | Identify features that the REST API needs to support, Refactor MediaWiki Core into well encapsulated components, removing global state and circular dependencies between classes | Output 2.1 | MediaWiki Platform | Services, Reading Infrastructure | 0 | 6 | Should be designed by a group consisting of members from the MW Platform team, Services, Readers and Contributors. This ensures that those who know the MW platform best, those who have experience designing REST services, and those who implement the clients all agree on the design | ||||||
Develop MediaWiki REST API | Implement the REST API incrementally by addressing one feature at a time in core | Make REST Routing possible in MediaWiki, Design MediaWiki REST API | Development | Output 2.1 | MediaWiki Platform | Services, Reading Infrastructure |