PragDave nails it. Again. 4
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: ;new and ;edit, offering up forms for clients too dumb to know how to build their own; and RJS helpers like ;preview, ;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.
My first reaction is that Dave’s definitely onto something. If nothing else it deals with one obvious wart involving authentication and REST. The problem is, a good RESTful application doesn’t roll its authentication, just uses HTTP Digest authentication or SSL or whatever. With a smart client that’s fine; smart clients know how to log off as well as on. Browsers don’t. Essentially, once you’ve logged on using HTTP authentication, you’re authenticated until you restart the browser, which is not necessarily what you need a lot of the time. So most applications use cookies for authentication because the application has rather more control over a cookie. But that’s not really very RESTful because the connection is now stateful. Disaster!
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.
A thought…
Hmm… suddenly the Zimki approach of writing everything in JavaScript is looking more attractive. If you write the presentation layer in JavaScript there’s nothing to stop it residing either on the server while talking to browsers with JavaScript turned off and running directly on the browser (entirely or partially as the case may be) and talking JSON to the REST kernel.
Or you could pull out all the stops and have a Seaside style front end, doing all that shiny continuation based, rich session magic that makes DabbleDB such an amazing bit of software; after all, Avi’s been busy showing people how to take Seaside’s ideas an implement ‘em in Ruby (or JavaScript…).
I wonder if Rails is malleable enough to get a proof of concept of this sort of thing up quickly?
I think there’s an interesting nugget in here, but there’s also some complications. In your comment on PragDave’s blog, you talked about wanting to get Ruby objects from the REST interface, as opposed to just serialized data.
I’m not a big fan of this sort of “pure pipeline” (my made-up term) approach. I think that inevitably the view code will end up replicating some large amount of logic that could be in the model, because now the view can no longer access to the model’s API. A similar issue shows up when you look at templating systems.
Also, I’m not convinced that all cookies are un-RESTful. RESTers claim that HTTP auth is stateless because the client sends its authentication with every request. But if your cookie just contains a user id and some sort of verification token, how is that not exactly like basic auth, minus the grotesque popup?
I think you (and they) are conflating cookie-based server-side sessions with all cookies.
I think we’re in violent agreement about it being a bad idea to throw away the model’s behaviour. Objects are not data structures dammit.
And yes, I am conflating sessions with authentication.
I think my underlying point is that sometimes rich behaviour needs more state than a browser can maintain by itself. Smart clients get to manage their own state, but browsers generally aren’t smart enough to manage that, so the presentation layer may need cookies, Seaside style stateful URLs or some other magic to maintain any state they need (not that all applications will need to maintain state of course).
“I wonder if Rails is malleable enough to get a proof of concept of this sort of thing up quickly?”
http://borges.rubyforge.org/
This sure feels like a lot of the ideas we’ve been playing with in Jifty.
Though too much of the world has decided that REST == CRUD….Which severely limits what you can do.