[uf-rest] RESTifying RAILs

[Dr. Ernie Prabhakar]

Hi Dan,

On Nov 4, 2005, at 1:12 PM, Dan Kubb wrote:
> Q: Is RESTifying Rails OT for this list?  Maybe it would be
> better to move this to rest-discuss or the Rails list?

Well, it might be, except that most of these issues transcend Rails;  
in fact, these are precisely the conceptual issues we created this  
list to discuss!  Having a concrete examples like Rails -- which is  
already 90% there -- is very useful discipline.   If we get to the  
point where start arguing Ruby syntax that would be bad, but in that  
case we'll probably have worse problems. :-)

>> My only concern is with your mechanism for handling other methods:
>> That seems a bit verbose, not to mention non-backward-compatible

> You're right, replacing the way rails dispatches to methods
> in the core would probably not be a good idea.  I was more
> thinking along the lines of providing a way for us to
> dynamically choose the exact method that was dispatched to
> within a controller...
>
> Also to expand on your idea about calling Person.index on
> GET:  What if the behavior for the RESTful dispatcher
> is to call Person.index ONLY if the corresponding
> Person.get_index wasn't available?  Likewise for PUT
> requests, it would use Person.index only if Person.put_index
> wasn't available.  I think that would be in-line with
> standard rails behavior.

Yes, that makes much more sense; sounds like the right approach.

> URI's are forever, but the representation is
> malleable, so thats where I decided to compromise.  I'm using
> a simple naming convention within the web form, like so:
>
>   <form method="post" action="/person/123">
>
>     <!-- ... some other fields containing attributes of the  
> person ... -->
>
>     <input type="hidden" name="method" value="put" />
>     <input type="submit" name="method_put" value="Save" />
>     <input type="submit" name="method_delete" value="Delete" />
>   </form>
>
> The logic to dispatch is buried inside the controller example
> I sent, but its pretty simple:
>
>     def tunneled_method
>       allowed_methods.find { |m| params['method_' + m] } || params 
> [:method]
>     end

Ah, very interesting. What's even more intriguing is that your  
approach -- even if slightly skanky from a REST perspective -- is the  
"right" solution from a microformats approach.  That is, I suspect  
that is how web sites *already* implement PUT and DELETE semantics  
over HTTP. And in the microformats world (even more than the REST  
world, I think) the focus is on "paving the cowpaths" of existing  
behavior, rather than worry about how "correct" it is.

> A plus to using naming conventions within the form is that
> javascript could be written so that when the appropriate button
> is clicked a real PUT and DELETE can be done via AJAX.

Ooh, even cooler.

> Yeah, I realize this is a hack, but it seems to work fine in
> practice.  Obviously I would prefer it if the HTML standards
> supported methods other than GET and POST, and if nested forms
> were allowed; but they aren't yet.  I am of course open to
> suggestions if there is a better way.

Yeah, I think you've hit the 80/20 tradeoff for this in the right  
place.  Nice!

Updated the wiki accordingly:

http://microformats.org/wiki/rest/rails

-- Ernie P.
------------
Ernest N. Prabhakar, Ph.D. <drernie at opendarwin.org>
Ex-Physicist, Marketing Weenie, and Dilettante Hacker
Probe-Hacker blog: http://www.opendarwin.org/~drernie/