QCon SF: Obie Fernandez -- "Desiging RESTful Rails applications"

These are my unedited notes from Obie Fernandez’s talk

• introduction to REST - Obie focuses on C/S architecture, stateless communication, and caching
• REST support in Rails: view helper methods and enhancements to the routing system
• more than a set of naming conventions
• benefits: convenience for the developer, a REST interface for everyone else
• much of Rails non-compliant with the precepts of REST
• every real-world Rails app contains sessions, uses cookies
• started out with Routing and CRUD
• it’s good to use CRUD-based names
• much of Rails’ REST support is easy generation of named routes
• example: map.resource :auctions - will create 4 named routes for 7 controller actions
• difference between resources and representations
• opinionated REST support
• emphasis: resources should not be confused with the actual physical things in your systems
• actual code samples - explanation of the link between the name of a route and the generated _path method
• instead of having auction\_path, auction\_delete\_path and auction\_create\_path, pick auction\_path and auctions\_path
• (it’s interesting to note that Obie uses a mix of speaking freely and obviously reading from notes. hm.)
• overloading based on the HTTP verb
• explanation of the stuff generated by map.resources :auctions (I’ll skip this, look it up)
• rules for request methods - default is GET, in form_tag or form_for, POST is used
• explanation of the PUT and DELETE hack
• creation and update require two “extra” actions (new and edit) to display the forms, kind of like a pre-resource
• extra named routes: new\_item\_path and edit\_item\_path
• singular named routes (map.resource instead of the plural form) allow you to identify things that exist only once
• yields address\_book\_url and address\_book\_path only
• example: login is something you’d model as a POST and DELETE on a single “session” resource (I find this entirely unconvincing)
• nested resources, example bids as nested resources of an auction
• /auctions/3/bids/5
• why not /bids/5? URL is more informative, longer URL allows access to the auction id via params[:auction\_id]
• nesting can be of any depth - recommendation: 2 levels at the most
• controller by default gets the same name as the (plural) resource name
• RESTful route customization: :members => { :retract => :get} within the nested bid resource
• :any instead of :get will map any sort of request to the same action
• instead of a retract action, a more RESTful way would be a retraction resource
• analogy: RESTfulness, like normalization, is not binary
• Pete Lacey suggests using a PUT with a new state to retract a bid
• Obie suggests the goal should be to keep your actions concise and to the point
• different representations of resources: responds_to (using .xml as an example)
• additional view helpers: formatted\_auction\_path(auction, "xml") (I didn’t know this)
• Question: When to add “.xml” to the end? What about the location header - should it point to the .xml
• Comment from the audience: some caches don’t cache if you don’t have an extension
• Ola Bini and Pete Lacey argue about status codes and text support in Rails
• Pete: will there be an ability to use something in the URL that doesn’t map to a controller
• Comment: there’s a separators array that allows you to customize this
• regexp mappings in route are possible
• conditions on routes allow for additional flexibility

I knew about 90% of all this, but the Q&A was helpful. Good talk.