Since we're considering
https://www.mediawiki.org/wiki/Requests_for_comment/Services_and_narrow_int…
and asking for discussion on
https://www.mediawiki.org/wiki/Requests_for_comment/Content_API , I put
some time into understanding what a Service-Oriented Architecture and
Representational State Transfer mean in general, and what they'd mean
for MediaWiki. Here's what I think we're talking about. Please correct
me where I'm wrong!
So, just to clarify, this is NOT a discussion of overhauling the
outward-facing MediaWiki web API -- that's taking place in
https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap .
Instead, this is about refactoring how MediaWiki works *internally*, for
everything from page editing to export to watchlists to permissions to
stats. (And we've already sort of started doing this; see how Parsoid
gives you parsing-as-a-service, for instance.)
The way we do stuff now: within your code, you write your core or
extension code so that it interacts with various objects, subclasses
this and event-handles that and hooks into the other thing. And there
are several files and classes and globals that you kind of have to
interact with to do many different things, like index.php and $wgTitle
and $mediawiki .
A service-oriented architecture would change this; instead, code authors
would be able to read and write data via services. You sort of see this
now, in how there's a Notifications service and a Parsoid service that
new core or extensions code can push to or read from. In an SOA, we'd
extend that to include LOTS of functionality - basically any retrieval
or modification of data that a new feature might request or activate
that, in a more monolithic architecture, would require direct database
access or other permanent data store.
REST (Representational State Transfer) is a model for how those services
would work. Any given chunk of data is a resource. We have well-defined
verbs in HTTP for the service's client to use when either asking for a
representation of that resource (GET) or suggesting a new representation
so as to get the service to change the state of the resource (often POST).
So the future might look like: the heart of MediaWiki core is PHP code
that talks to the database and provides well-defined interfaces for
other components to talk to by saying, e.g., GET /pages/123 , PUT
/pages/123 . There are a bunch of examples in
https://www.mediawiki.org/wiki/Requests_for_comment/Storage_service_and_con…
although I don't quite understand the question marks in the URIs.
Is this about right?
---------------------
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation