REST is easy, it’s just smart clients using HTTP to the full.
Except, as Dave ‘PragDave’ Thomas points out, browsers aren’t smart. They’re just dumb terminals with prettier graphics.
And what does that mean? It means that a typical Rails controller is trying to multiplex two protocols in the same chunk of code. There’s the pure four and then there’s the others:
;edit, offering up forms for clients too dumb to know how to build their own; and RJS helpers like
;autocomplete and whatever else you need to do server side to make the Browser look smart.
But when you have a class that’s trying to be two things at once, you really have two classes, you just don’t know it yet.
So, Dave proposes splitting controllers; write a RESTful controller that only has to concern itself with serving up resources that smart clients can reuse and remix as appropriate. Then, you a server side smart client that decorates your resources with all the scaffolding that a browser needs.
Dave calls this RADAR: RESTful Application talking to Dumb Ass Recipient.
However, if you decompose your application along RADAR lines, all the conversation with the REST kernel continues on its stateless way, but the combination of your browser presentation layer and the browser share a bit of state through cookies (and possibly a session) in order to do a better imitation of a smart client.
I wonder if Rails is malleable enough to get a proof of concept of this sort of thing up quickly?