RIBS: Marrying the REST and MVC Design Patterns
September 26, 2011 § 1 Comment
[Diagram updated on 10/27. Thanks to @frozencanuck for his feedback.]
The RIBS diagram is my third attempt to extend the wildly-succesful Model–View–Controller design pattern to encompass first the The DCI Architecture and now the REST architectural style. This time, I started by reverse-engineered the design principles behind the Ki Statechart Framework, particularly their use of statecharts as coordinating controllers.
I also have a clearer picture of what I am doing: trying to identify a general design pattern for computational systems.
Here’s what it looks like so far:
- The purpose of a System is to manage a Resource
- A System contains a Resource, one or more States and their Behaviors, an Interface for each State, plus relationships with zero or more Peers.
- An Interface (which could also be a System of its own) consists of active Actions and passive Presentations available to an external Client.
- When a Client invokes an Action, the System routes it to the appropriate Behavior for the current State (the routing is necessary if there are multiple concurrent states, otherwise it can be elided).
- A Behavior can in general a) adapt a Resource, b) interact with a Peer, and c) initiate additional Behavior
- Resources present to an Interface and adapt to a Behavior
- Views are Interfaces
- Models are Resources that can adapt and present themselves
- Controllers manage State, routing, and connections with Peers
- Views can be systems, whose Resource is a drawing context and Behavior is hit detection
- A Model object could itself be a system, with a database row as its Resource and business logic as its Behavior
- Hypertext is an Interface (HTML) which uses Routes (URLs) to embed State
- Behavior is driven by a small set of Actions (HTTP verbs) against a specific Resource