[LRUG] REST and Associations

[Piers Cawley]

Eleanor <eleanor at goth-chic.org> writes:
> On 22 Feb 2007, at 22:02, Roland Swingler wrote:
>> 4. The urls nested resources produces only seems to make sense for the
>> new / index /create actions - by the time the resource has a unique id
>> it already has a unique url, because the id is unique - but there
>> doesn't seem to be any way to disable the urls you don't want.
>
> You've just eluded to the single biggest flaw in Rails' URI  
> conventions. Exposing database IDs over the network is a very bad  
> idea and everyone should write their applications to use public  
> resource names rather than IDs. In real-world applications it will  
> have minimal impact on database query performance (after all, you are  
> using indexes I hope!) and at the same time will make your URIs much  
> more robust. Otherwise you're handing implementation-dependent detail  
> to any random third-party that wants to explore your application, and  
> constraining your public interface to a static view of your data.  
> You're also breaking a key tenet of user interface design - a URI is  
> intended to be a human-friendly resource identifier and as such  
> should use meaningful semantics wherever possible to simplify the  
> user experience!
>
> Instead of:
>
> 	/posts/1
>
> you should favour:
>
> 	/posts/my-views-on-REST
> or
> 	/posts?title=my-views-on-REST&version=0.1
> or
> 	/posts?year=2006&month=December&category=REST&author=all
> or
> 	/posts/2006/December/REST
>
> none of which expose your database IDs, and all of which can point to  
> the same resource, allowing users to remember whichever style of URI  
> makes most sense to them as well as making educated guesses about how  
> to search for other resources in your application.

Wild applause from this corner of the internet. Supporting this sort
of thing in Rails is a PITA at the moment. Roll on some plugins to
make life easier.

> This is where the environment/routes.rb file comes in to play. Some  
> useful resources on Rails routes include:
>
> 	http://www.pinupgeek.com/2006/5/24/rails-routing-demystified
> 	http://www.afreshcup.com/2007/2/9/basic-routing-in-rails
>
> but these all tend to be pretty basic. I've yet to find any really  
> deep geek articles on the subject, although LRUGer Paul Battley has  
> done some interesting work on a procedural alternative to the  
> standard routing model so he might be able to suggest appropriate  
> resources.

The problem I have with the current routing approach is that you have
to know too much to generate them. If I've got things set up so that
(for instance) comments are nested within articles, then I don't want
to have to call 'comment_url comment.article, comment'. And, when my
default article URL is of the form:

   /articles/2006/06/01/article-title

I want to generate that with a call to 'article_url article' rather
than the current mess: 

    url_for :year => article.year, :month => article.month, 
            :mday => article.day, :slug => article.slug

Maybe if #to_param. I'm currently toying with implementing a
#to_url_hash method on my models, which will generate an appropriate
hash to pass to url_for... or maybe extending routing so one could
specify:

   /articles/:article[year]/:article[month]/:article[day]/:article[slug]

>> 5. For nested resources, how do you avoid a dirty great switch
>> statement in your controller if things can be nested under many
>> different resources?

In acts_as_resource I handle this by having the models know their
'parent'. If you can reach the same controller by multiply nested
paths, then the relationship with the parent will be polymorphic. Any
given instance of a model that acts_as_resource can generate the chain
of resource objects by which it can be reached simply by walking up
its chain of parents. Once you have models being able to trace a path
to the root of the resource tree you're laughing and can write a
generic #find_resources method that will find the appropriate
resources without having to resort to a huge switch statement. 

-- 
Piers Cawley <pdcawley at bofh.org.uk>
http://www.bofh.org.uk/