[uf-rest] RESTifying RAILs

[Dr. Ernie Prabhakar]

HI Dan,

On Nov 3, 2005, at 11:50 PM, Dan Kubb wrote:
> I've been thinking about how to RESTify Rails for the
> last week, and have been RESTifying other MVC systems
> for several months, so I've got a few points to add.

Wow, great stuff.   I've added your new items to the Wiki:

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

I just hope we don't freak out David with too many ideas. :-)  I  
appreciate your willingness to actually prototype this in code, so  
(assuming David agrees) the implementation should be relatively  
painless.

My only concern is with your mechanism for handling other methods:

>   GET     /person/            -> Person.get_index
>   GET     /person/123         -> Person.get_index
>   GET     /person/123/friend  -> Person.get_friend
>   HEAD    /person/            -> Person.get_index   # HEAD handled  
> by get method
>   POST    /person/            -> Person.post_index
>   PUT     /person/123         -> Person.put_index
>   POST    /person/123/friend  -> Person.post_friend
>   DELETE  /person/123         -> Person.delete_index
>   DELETE  /person/123/friend  -> Person.delete_friend

That seems a bit verbose, not to mention non-backward-compatible.   
I'd prefer something like:


>   GET     /person/123         -> Person.index
>   POST     /person/123         -> Person.index_POST

That is, the default is GET as usual, but one can suffix a method to  
indicate a special response.  I also think using ALL CAPS is better  
to a) avoid collision with normal URIs and b) signal clearly that  
this is special.  Though, is CAPS in a method name bad Ruby hygiene?

Also, one question:

> One other thing this Controller is doing is that it
> allows tunneling of PUT, DELETE (and any other method) over
> top of a POST.  Before dispatch I look for a specific
> parameter that says what method I really want to call
> and dispatch to it.

Yeah, we're still wrestling with that issue.

> While this isn't RESTful, its a trade-off that will allow
> the web apps to work with all browsers until support
> for more than GET and POST is common.

Actually, there might be another way -- automatically insert the  
necessary JavaScript to synthesize the request from a form:

http://jibbering.com/2002/4/httprequest.html

If we're controlling the generated HTML anyway, why not solve it on  
the client-side?  This is a browser limitation, so better to fix it  
there; and if from the designer's point of view it is zero-cost why  
not pretend to do the right thing?

>   Hey I've got to tunnel update and delete operations over POST  
> somehow

Well, Dimitri might disagree. :-)

> anyway, so I figure I'll use a convention to do it.

So, what convention to you use, exactly?  Explicitly specifying a  
"put_index" URI?

-- 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/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-rest/attachments/20051104/12fca416/attachment-0001.htm