Zach Copley

Last Tuesday I attended the East Bay Ruby Meetup. For some reason, I thought the meeting was going to be a project showcase in which local Rubyists would show off their pet Ruby projects, but instead we had a “RESTful Rails” live coding demo. Will Sobel, the organizer of the meeting, said something about one of the other speakers flaking.

Jimmy Kittiyachavalit was the speaker/presenter (everyone called him Jim). He works at a shop that uses Rails and has adopted the REST methodology and architecture for their applications. He’s an extremely smart and entertaining guy who can type at about one million miles per hour.

Like a lot of Rails people, Jim uses a Mac (looked like a MacBook Pro), but unlike many Mac people he seems very Unix-minded. I could tell he’s one of those guys who doesn’t like to take his hands off the keyboard to move a mouse cursor around. He uses Quicksilver to launch his apps, and minimizes the OS X dock almost completely out of existence. I’ve never seen anyone as efficient at using vim as Jim, he has mad vim skillz. Rails apps (like most Web apps) have boatloads of little files littered across a slew of directories, but he could dash through them using auto-completion and other vim tricks just as fast as I can move through them using TextMate’s GUI project management features.

In less than two hours, “in front of a live audience,” Jim built a small, RESTful social networking application, replete with users, groups, friends lists, and user auth. He coded and debugged–ocassionally with help from the peanut gallery–and answered questions along the way. Code flew by in blur, but I think I got about 80% of what he was doing.

REST

I’ve heard the term REST and glanced at a couple of articles about it, but I wasn’t really aware of its history, and that it’s a whole development methodology. The Ruby community is bigtime into REST.

REST stands for Representational State Transfer, a term coined by Roy Fielding, one of the designers of the HTTP protocol. In his dissertation he wrote about REST being the main principle behind the rapid expansion of the Web. He came up with this REST stuff back in 2000 (or maybe even earlier), so REST has been around for a long time in dog years. I feel a little unsettled and weird I don’t already have REST under my belt and fully internalized, considering I’ve been working on Web applications for the better part of a decade. On the other hand, I think it’s just relatively recently people have been focusing on it and rigorously trying to apply its principles to building Web applications and Web services.

Frankly, at this point I’m not sure I’m won over to the REST methodology, but I’m studying on it. The reasons why you should build your app the RESTful way are still a little sketchy in my head. I guess REST is supposed to be a better architecture. RESTfulness is supposed to make your application simpler, safer and more interoperable. Plus, is gives you that good feeling of being in harmony with the true magical spirit of the Web.

The main idea seems to be that database CRUD operations (Create, Retrieve, Update, Delete) are already built into the HTTP protocol; they map to the HTTP methods POST, GET, PUT, and DELETE respectively. Everything in a RESTful app should be as stateless as possible, and everything, including the logic for relationships between objects, should be a named resource REST operations can be applied to. So, adding a new record (for a User, say) should be accomplished with HTTP POST, updating the record would be done with HTTP PUT, etc., and when you want to relate a “User” object to a “Group” object there needs to be a relationship object (e.g.: GroupMembership) that can be manipulated RESTfully.

One nice thing about this strategy is there’s never any question about where to put the logic relating a User to a Group, for instance. Should it go in the User code or Group code? The REST way is to put it in its own object, probably linked to a special “group_membership” table in the database. I would have done it that way anyway, based on experience, but I guess the REST methodology formalizes and encapsulates that wisdom. Other benefits include an elegance and consistency to your architecture, and the fact that everyone working on your application will know where to go in the code to find things.

On the other hand, it seems like apps that require a lot of state saving, such as AJAX-oriented apps and stuff, do not really mesh too well with RESTfulness. User authentication was sort of a sticky point in Jim’s app, where he had to fudge a little on REST purity, because user auth is naturally stateful. As he put it, “user authentication and REST sort of butt heads.” Another possible downside is your application’s data model tends to get big and complex fast because there are so many objects/tables. (That tends to happen anyway with complicated applications.) I also wonder about security. Even though “security through obscurity” is probably not the best protection, if it’s obvious to everyone where key functionality lives in your application, it’s gotta be easier for bad haxors to zero in on it. But Jim didn’t seem to think that was a big issue when I asked.

There seems to be pretty good REST support in Rails, including special scaffolds, and special URL helper methods in the routing configuration (routes.rb). Support doesn’t seem 100% there yet. Jim said you have to constantly restart your Web server when you’re writing REST apps in development mode (which he did a lot during his presentation) because you’re constantly editing the configuration files. That kinda sucks. One of the great thing about Rails is you hardly ever need to restart your Web server to deploy new code and other functionality during development.

ActiveResource

One really cool thing brought up at the end of the presentation was ActiveResource, which is based on or inspired by the ActiveRecord ORM. The idea is that instead of only using REST for local database CRUD operations, your app can access remote resources over the Web with REST. In other words, it’s another lightweight form of Web services. The persistence for your application could be something accessed via HTTP, maybe something like Amazon S3, or your app could simply make REST calls to decoupled remote resources.

Useful links and references bandied about

• Architectural Styles and the Design of Network-based Software Architectures — Fielding’s dissertation, which outlines REST
• David Heinemeier Hansson RailsConf ‘06 Keynote — an influential presentation that helped kick start interest in RESTful Rails
• PDF-format slides used during Hansson’s keynote
• Skinny Controller, Fat Model, by Jamis Buck — Article about the benefits of the RESTful way
• Beast — A RESTful forum built using roughly 500 lines of code and useful to look at while learning REST
• The Freenode #rubyonrails IRC channel — Jim spends a lot of time in there. A good place to ask questions about Rails and REST. Also: the Freenode homepage