Since we're considering https://www.mediawiki.org/wiki/Requests_for_comment/Services_and_narrow_inte... 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_cont... although I don't quite understand the question marks in the URIs.
Is this about right?
--------------------- Sumana Harihareswara Senior Technical Writer Wikimedia Foundation