This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

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

Stefan Tilkov,

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.