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:

Resource • Interface • Behavior • State

  1. The purpose of a System is to manage a Resource
  2. A System contains a Resource, one or more States and their Behaviors, an Interface for each State, plus relationships with zero or more Peers.
  3. An Interface (which could also be a System of its own) consists of active Actions and passive Presentations available to an external Client.
  4. 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).
  5. A Behavior can in general a) adapt a Resource, b) interact with a Peer, and  c) initiate additional Behavior
  6. Resources present to an Interface and adapt to a Behavior
Importantly, this is a conceptual document, not a software architecture.  To be sure, it is intended to map easily onto traditional MVC objects:
  • Views are Interfaces
  • Models are Resources that can adapt and present themselves
  • Controllers manage State, routing, and connections with Peers
This implies that traditional MVC concepts are actually aggregates of other, more primitive concepts.  Indeed, advanced programmers often add presenters, adapters, routers, state machines, and behavioral strategies in order to overcome the brittleness of pure MVC.
However, the RIBS pattern is actually more general than that, because it applies even below the object level:
  • 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
You might say that one system’s Interface is another system’s Resource.  In fact, RIBS can also be used at a much higher level to describe RESTful web services:
  • 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
In short, a RESTful system pulls the State into the Interface enabling you to work directly with Resources.
At least, thats the theory, as best I currently understand it and can articulate it. What do you think? Can you do better?

ActiveResource: The RESTful standard

September 27, 2007 § 1 Comment

One of the coolest if under-hyped features of RESTful Ruby on Rails is ActiveResource.  This allows you to treat any other RESTful Rails app as a database backend, providing an ActiveRecord like object model for abstracting that web service.Though changing slightly for Rails 2.0 (to use “/” instead of “;” as a parameter separator), this is becoming the de-facto standard for how to express RESTful URLs.  Work appears to be going on in both Python and Java.  There’s also a really cool JavaScript client.

Rohit’s SynOA takes the “Sin” out of SOA

September 24, 2007 § 1 Comment

Many years ago, my buddy Rohit Khare introduced me to a guy named Roy Fielding, and tried to explain how this whole web services thing was going in completely the wrong direction. To be honest, I didn’t understand what the big deal was, particularly since I wasn’t really working with those technologies. Alas, neither did the rest of the industry which was rushing headlong into what become Service-Oriented Architectures.

Fast forward to 2006, when I finally understood (and became enamored of) Roy’s RESTful architectures (which I helped pitch to DHH for Rails 1.2). The problem now was figuring out how to help people understand REST in terms of a specific implementation, rather than Roy’s highly abstract architecture. Several of us have experimented with using the excellent Atom Publishing Protocol (APP) as both a model and foundation for building a RESTful alternative to traditional web services, but that was as far as we went.

Rohit (as usual) went one step further by coining (and describing) the term Syndication-oriented architecture at the Gartner Financial Service Technology Summit. The key idea (IMHO) is to use the additional constraints of REST in general, and APP in particular, to minimize variance and thus enable greater interoperability. His initial paper was published by KnowNow on August 27, 2007, but only noticed by a few folks like Bruce MacVarish. The meme didn’t really gather steam until Rohit was interviewed by Jon Udell. That was in turn blogged in Kurt Cagle’s O’ReillyNet column (among others), and as of September 24th I count over 10,000 Google hits for “SynOA syndication.”

I think SynOA could well turn out to be the “tipping point” for both REST and Syndication; though obviously we still have a long way to go

Steve Bjorg: The Story of the REST

May 9, 2007 § Leave a comment

With apologies to Paul Harvey, here’s another Introduction to REST, courtesy of Steve Bjorg (with a little help from yours truly).

OpenID: The RESTful approach to Single Sign-On

December 7, 2006 § Leave a comment

Been spending a lot of time on
regular
work
, but a friend recently
suggested I check out
OpenID
— the de facto distributed authentication standard for Web 2.0. I think of it
as “Decentralized Kerberos for the Internet”, in that provides the ability to do
Single Sign-On without the need for everyone to agree on a single directory
server or implement a bunch of hairy
protocols.

If I understand
it correctly, all you need is:

? an account with an OpenID
Provider (usually, but not necessarily, a username and password)
? a publicly-reachable URL
with an autodiscovery link to one or more Providers (like the links to RSS/Atom
feeds)

If you’re
ambitious/paranoid, you can even be your own provider. The reason is that the
“principal” (globally unique identifier) is really the URL (or a weird mutant
threof, like an
XRI).
All the Provider does is validate that you (as defined by your login information
with them) have access to that URL. That’s it — pure authentication, no
authorization whatsoever. All it is doing is ensuring that nobody else can claim
that URL.

To use it, you
just tell a Consuming website, “Hey, this is my URL: I’d like to use it as my
OpenID identifier on your website.” Then, they deference that URL, find its
Provider, and (if necessary) jump you over to the Provider’s website to
authenticate (and, optionally — if you allow — get your basic
name/email/contact data). Once that’s done, they can let you setup a local
‘nickname’ (not globally unique) to avoid the need for the complete URL.
Importantly, though, you never have to give a password (or any data you’d like
to keep private) to any Consuming site, and
they
never (really) need to trust the Provider; they just trust DNS and HTTP
(hopefully HTTPS) to ensure that you really have the right to claim that
link.

Now, in practice
there will probably be concerns about spoofing, so Consuming sites will have
whitelists, and which is why you may need multiple Providers to ensure they have
one that works everywhere they need it. But — crucially — all of that is an
out-of-band business opportunity. The protocol itself is (so I’m told) drop-dead
simple, so that (if you’re starting from scratch) you can get up and running in
a couple hours, especially if you leverage the pre-built libraries for PHP,
Ruby, Python, etc.

Most
importantly, it sounds like they really believe the “collaborative intelligence”
part of the Web 2.0 hype. They’re working with Dick of
Sxip,
Technorati,
and even some
SAML
refugees. If they can keep everyone happy without falling prey to bloatware,
they may really have
something.

And oh yeah:
their protocol appears to be thoroughly
RESTful,
so it plays nicely with the web.
Woot!

References
below.

« Read the rest of this entry »

A Theology of REST?

April 10, 2006 § Leave a comment

Over on REST discuss, transplanted Ghanese IBMer Koranteng
Ofosu-Amaah
posted a fascinating economic analysis of REST. [Read more] for some
choice excerpts from his Biblically-inspired parable(emphasis mine); I should
ask him if he knows economist-theologian Sayo
Ajiboye
!

« Read the rest of this entry »

Sam Ruby goes Jeff Foxworthy on REST vs. SOAP

March 23, 2006 § Leave a comment

SAM got a little wistful today about this ancient post where he hoped that the REST vs.
SOAP debate would focus on substantive issues. [Read more] to see why he isn’t
giving up his day job…

« Read the rest of this entry »

REST defined, concisely

March 20, 2006 § Leave a comment

Hat tip to Sam Ruby for pointing me to Koranteng
Ofosu-Amaah
‘s recap of the “REST Elevator Pitch” as four brief
points:
? Identification Of Resources
? Manipulation Of Resources Through
Representations
? Self-Descriptive Messages
? Hypermedia As The Engine Of Application
State

[Read more] for a longer,
metaphor-laden excerpt from Koranteng’s Toli about the
“HUHXtable (?) quartet.”

« Read the rest of this entry »

New Microrformats-REST wiki, mailing list

October 28, 2005 § Leave a comment

The interest in using microformats with REST has
grown so strong, Tantek suggested a new microformats-rest mailing list.

http://microformats.org/discuss/mail/microformats-rest/

I’ve
similarly created a new section of the wiki devoted to these RESTy
issues:

http://microformats.org/wiki/rest

I’ve
tried to collect all the relevant rest work from elsewhere on the wiki, as well
as external resources (like toydi’s excellent preso). I encourage you to sign
up (if you haven’t yet) and add your own data and comments.

« Read the rest of this entry »

Where Am I?

You are currently browsing the REST category at iHack, therefore iBlog.