« Jason Fried: Things We've Learned at 37signals | Main | Web Analytics 2.0 »

September 17, 2008

David Heinemeier Hansson: Go REST with Rails

Listening to David Heinemeier Hansson speak at NYC Web 2.0 Expo. He's talking about using a good practice for organizing web pages with proper building of page URLs.

David started in REST for practical reasons. Decided that Basecamp should have an API. Looked at the Flickr API, which says it's REST but isn't really true. Found the REST experience for the first go-around unsatisfying. Was just an add-on.

REST is based on HTTP, is a way of embracing it. HTTP is an ogre, which has layers. The HTTP spec has been around for a long time, but nobody had read it. The strength and weakness of HTTP is that you can use it without knowing anything about it.

REST is "blue cheese", an acquired taste. Took some time to get used to it.

Initial barriers to using REST. First, is the Roy Fielding dissertation which describes it. Roy's document is a dissertation, and is very academic. David quotes from it, very conceptual and complex language. Second, the ws-star group of specs and SOAP looks more organized and easy to step into. But after going down that path you realize that it's a bad approach.

David goes into a demo, using rails. It's like watching the 10-minute screencast.

REST relies on concept that there is a single resource that you can do multiple things too. E.g. /posts/1 is the URL for viewing, editing, saving (put) and deleting. They simulate the full HTTP get/post/put/delete actions even though they aren't valid in HTML. Also using the same URL for getting different formats. Also use that URL for saving new data.

If web servers and applications were built right, you'd be able to ask for a resource in a certain format and the browser would reply with a 406 response indicating that the resource is available but not in the format you were requesting. Rails differentiates between resource formats by using the same URL, but appending an extension (.html, .xml, .atom).

HTTP response 422 means unprocessable entity. So if you post something, but not quite right the 422 helps you know that you're close but might be missing some important data. With RAILS, the exceptions that result in a 422 is seamlessly handled in an XML request and HTTP. In XML, the response is wrapped in XML, in HTTP the browser gets and presents the message.

HTTP is so much better than SOAP from a human readability perspective.

David is passionate (well known) about the fact that if you use the HTTP REST principles it removes a bunch of stuff about decisions that just don't matter. Engineers/developers often spend time deciding how to organize the primary methods for interacting with data via a URL. With REST, it's all defined and you can move on to more interesting things.

The REST actions map to the HTTP actions, which map to database interactions:

find/create/update/destory -> GET, POST, PUT, DELETE -> SELECT, INSERT, UPDATE, DELETE

Posted by mike at September 17, 2008 12:04 PM