[uf-rest] RESTifying RAILs

[David Heinemeier Hansson]

> A big welcome to new member David Hanssonn, who is probably best  
> known to you for an obscure little app framework he wrote in Ruby. :-)

Hi guys...

> == REST-style URIs ==
>
> That is, make the default URL style:
>     http://host/base/table/id/style
> as in:
>     http://localhost:3000/mydemo/person/113
>
> for the default view, with an optional "/edit" on the end for,  
> e.g., forms vs. a list.
>
> This is subtly different than the current "table/action/id" which  
> scaffolding generates.   The central concept in REST is that every  
> object (noun) should have a unique URI, and having an action  
> inlined screws that up.

I'm actually using this style already myself. Here's the implementation:

   map.connect  ':controller/:action', :action =>  
'index', :requirements => { :action => /[^\d]+/ }
   map.connect  ':controller/:id', :action => 'show', :requirements  
=> { :id => /[\d]+/ }
   map.connect  ':controller/:id/:action'

This makes people/create and people/1/edit work. But this only works  
as long as your ids are integers. But that's a reasonable assumption  
for scaffolding. And I'm forcing that assumption to be true in all of  
my apps anyway.

Post 1.0, I'm definitely into making that the standard. people/show/1  
hurts my aesthetics now too.

> == POST vs. GET ==
>
> Right now, as far as I can tell, Rails doesn't differentiate  
> results from a POST vs. results from a GET.  Those are semantically  
> different in REST, so I'd like [to know] a way to handle that cleanly.

class PeopleController < ActiveController::Base
   def person
     case request.method
       when :post
         Person.find(params[:id]).update_attributes(params[:person])
         redirect_to :whatever

       when :get
         @person = Person.find(params[:id])
         render

       when :options
         # something sensible

       when :head
         render :nothing => true, :status => 403
     end
   end
end

What's wrong with this style?

Stuff like person_POST seriously hurts my aesthetics. I might be  
persuaded to something like:

class PersonController < ActiveController::Base
   use_rest_routing

   def post
     Person.find(params[:id]).update_attributes(params[:person])
     redirect_to :whatever
   end

   def get
     @person = Person.find(params[:id])
   end
end

...or perhaps instead of use_rest_routing having something like  
ActiveController::REST

But to be honest, I don't know how helpful that would be. Casing on  
request.method seem more generally applicable, flexible, and less  
intrusive.

> == XOXO-style templates ==
>
> I'd like the default rhtml templates to be XOXO-compatible (e.g.,  
> dt/dd rather than <p><br>).

As long as we can make it look nice and natural, I have no problem  
with this. This should be a really easy patch.

> == Columns as class names ==
>
> In addition to 'human_readable' column names, I'd like there to be  
> a parameter for the equivalent 'css-friendly' representation of  
> those columns -- and for the default templates to include that.

I'm not sure I follow? What's a css-friendly way? Couldn't you use  
just the attribute names themselves, like "first_name"?

> == Complete, functioning, customizable web application ==
>
> I want to be able to do something like:
>
>     $ script/generate rex modelA modelB
>
> And get a full-blown web application which includes:
> * the front page, including navigation links to various model objects.
> * search boxes
> * entry forms
> * AHAH (ajax) responses
> * both list- and table- oriented model representations
>
> The ideal is that I could use a combination of CSS and AHAH to  
> generate the desired look, feel, and behavior of my website without  
> actually having to touch existing HTML.  As a bonus, I also want it  
> complete enough that I can write a REST-spider to easily discover  
> all the valid URIs and queries.  Hey, a guy can dream...

This would make a great plugin. And should be fairly manageable to do.

> == XOXO instead of YAML for configuration ==
>
> Okay, this last one is really nit-picky, and a little odd, but it  
> would (IMHO) be more consistent. Right now, the config is the only  
> non-HTML, non-Ruby file, and I at least had never seen YAML before  
> so it looked out of place.  Granted, using XHTML for config files  
> is a little freaky at first, but when you think about it, its no  
> worse than using custom XML tags (and way more interoperable). I'll  
> even write the Ruby serializer myself if I have to...

Well, we're actually phasing out YAML in favor of pure Ruby  
configuration. See the new environment.rb and routes.rb as examples.  
So I don't think this will be immediately relevant.

Thanks a bunch for opening up the discussion here. It's great stuff.
--
David Heinemeier Hansson
http://www.37signals.com    -- Basecamp, Backpack, Writeboard, Tada
http://www.loudthinking.com -- Broadcasting Brain
http://www.rubyonrails.com  -- Web-application framework