There are two basic strategies for keeping a changing URL pointing to the same content. Either only part of the URL changes and you look things up by the stable piece (as with the slugs in my previous blog post) or you keep track of old identifiers with pointers to their current identifiers.

On NearbyGamers, tags are used to identify what games players are open to playing. But there are a huge number of variations: the game Dungeons and Dragons might be listed as D&D, DND, D&D 4, D&D 4th ed., or many more (and that’s before spelling errors).

To deal with this, I borrowed a mechanism from Wikipedia. Users can edit a tag to redirect it to another (which may not have a redirect set to a third, to prevent all sorts of annoying problems). In short, the Tag object might just be used for its column pointing to another Tag.

This is functionally equivalent to having a table of redirects. When a request comes in for a particular Tag, I could check a TagRedirect table to see if that tag appears in the from column and redirect the visitor to the Tag named by the to column.

Redirects are one of the ways your app will have to scale to meet users’ activity. Thinking about redirects as an explicit table makes it clear you have options for how to deal with it: you could add a date column and expire old entries, or limit the number of redirects one user is allowed to make (perhaps over time), or limit the number of redirects one entity allows. You could even replace this database table with a distributed key/value store like memcached (or preferably something more permanent).

So allowing users to edit URLs leads to one of three things: either you don’t allow them to edit the real identifier, you maintain a table of redirects, or you accept broken links.

NearbyGamers also uses the third strategy: if a gamer changes their handle, the URL is updated without any kind of redirecting. I considered redirects, but then no one could ever relinquish a handle.

URL design is not easy. Allowing users to influence what a URL will be is often really valuable but adds to the difficulty of designing your URLs. This is one of the interesting bits of computer programming where there isn’t a single answer, you have to pick your tradeoffs to match your needs.

In the explanation of named routes, there’s a series of examples demonstrating the increasing amounts of syntactic sugar Rails provides:

 
# The most explicit way, before you define the named route:
<%= link_to "Auction for #{h(auction.item.description)}",
    :controller => "auctions",
    :action     => "show",
    :id         => auction.id %>
 
# The first use of the named route, no need to specify controller or action:
<%= link_to "Auction for #{h(auction.item.description)}", auction_path(:id => auction.id) %>
 
# If you just have an :id argument to fill in, you can just pass the value:
<%= link_to "Auction for #{h(auction.item.description)}", auction_path(auction.id) %>
 
# And you could just pass the object and Rails will get its id:
<%= link_to "Auction for #{h(auction.item.description)}", auction_path(auction) %>

In Rails it’s just syntactic sugar, but the underlying mechanism here is type coercion. Instead of thinking of a URL having the type ‘string’, think of it having the type ‘URL’. (Here’s where all the Haskell guys are saying “Uh, it does already.” and rolling their eyes. You already get it, so this post is not for you.) The syntactic sugar is quietly converting an auction object into a url object (or part of one, really).

In Rails you can define a to_param method on your object that’s called by url_for (the method underlying link_to), and the name gives away that you’re converting type like the to_i, to_s, to_f methods you already know from Ruby’s builtin types.

The reverse is less seamless. There is no Model.from_param. Rails’ routing unpacks the URL into variables for the code you write in your controller to find the object(s). In a RESTful style, it seems odd that Rails doesn’t default to doing something like @model_name = Model.find(params[:id]) if you don’t define your own load_object before_filter.

I’ve been thinking a lot about REST lately. The URL of a resource is that resource converted to a URL type. A view presenting an object could be considered converting it to an HTML type. Controllers and actions… I can’t quite see putting them into my models, but they seem much less distinct to me than they did a few hours ago.

human-readable

I should get some idea of what the discussion’s about when I hover over a link

permanent

bookmarks, incoming links, and search engines all need reliable URLs

editable

If a discussion drifts, it needs a new subject, which means it needs a new URL

opaque

I’d rather not roll out the carpet for someone to scrape all the discussions

After a bit of pondering, I decided that URLs should look like this:

http://nearbygamers.com/discussions/{slug}-{post count}-{subject}

slug

An unchanging random 5-character string.

post count

The number of posts in this discussion, so that when you look at the discussions index you know at a glance if you’ve read a thread because your browser colors visited links. I snagged this off the Joel.

subject

Just the alphanumerics, dash-separated, updated as the subject is edited

So two parts (post count and subject) on a discussion can change, and the controller uses the slug to load the discussion and redirect to the correct URL if either has changed. Bookmarks and search engines can update, and outside links never stop working.

The Code

First, a little snippet of code to generate slugs lives in lib/slug.rb:

 
def random_slug(length=5)
  chars = ("a".."z").to_a + ("A".."Z").to_a + ("1".."9").to_a
  Array.new(length, '').collect{chars[rand(chars.size)]}.join
end

The Discussion model uses this to set a slug on itself if it doesn’t have one yet, and then uses that slug to generate URLs (note that I remove multiple and leading/trailing hyphens from the subjects):

 
require 'slug'
 
class Discussion < ActiveRecord::Base
  def to_param
    "#{slug}-#{posts.count}-#{subject.gsub(/[^[:alnum:]]+/i, '-').gsub(/-+/, '-').gsub(/^-|-$/, '')}"
  end
 
  protected
  def before_validation
    if self.slug.empty?
      begin
        self.slug = random_slug
      end while(Discussion.count(:conditions => ['slug = ?', self.slug]) > 0)
    end
  end
end

Finally, the DiscussionsController loads discussion objects, throws 404 errors, and redirects appropriately:

 
class DiscussionsController < ApplicationController
  before_filter :load_discussion, :except => [ :index ]
 
  private
  def load_discussion
    slug = params[:id].split('-').first if params[:id]
    @discussion = Discussion.find_by_slug(slug) if slug
    raise ::ActionController::RoutingError, "Recognition failed for #{request.path}" if @discussion.nil?
    redirect_to discussion_path(@discussion) and return if @discussion.to_param != params[:id]
  end

On Sunday I updated gamers and tags to use ActiveResource. It wasn’t hard, mostly just renames (the ‘view’ action became ‘show’, for example) and removing url_for hashes (:controller => 'gamers', :action => 'view', :handle => @gamer.handle) with much nicer named routes (gamer_path(@gamer)). A gripe I have about ActiveResource is that it has poor URLs, with internal record IDs leaking out. I’ve had nice URLs (/gamers/Harkins and /tags/RPGs) for gamers and tags and I wanted to keep them.

Joshua Schacter gave a presentation on building and growing del.icio.us that included the gems (among many other gems):

• Dont expose your unique id’s to the outside world (php?id=1 etc.) people can scrape through everything very easily. This is why del.icio.us uses MD5 hashes of links instead.
• URLs are prime real estate – respect them

It turns out this is not just possible but easy, though I blew an hour or so finding it (Rails docs still need love). In my Gamer and Tag objects, I just define a to_param method and the URL builder picks it up:

 
class Gamer < ActiveRecord::Base
  def to_param
    self.handle
  end
end
class Tag < ActiveRecord::Base
  def to_param
    self.name
  end
end
 
# and over in config/routes.rb I do the usual:
map.resources :gamers
map.resources :tags, :memger => { :history => :get, :variantes => :get }
# and now gamer_path(@gamer) and tag_path(@tag) work in my views

My controller looks like:

 
class GamersController < ApplicationController
  before_filter :load_gamer, :except => [ :index ]
 
  # The regular index, show, edit, and update actions here
 
  private
  def load_gamer
    @gamer = Gamer.find_by_handle(params[:id], :include => [:location, :tags])
    raise ::ActionController::RoutingError, "Recognition failed for #{request.path}" if @gamer.nil?
    # canonicalize case
    redirect_to gamer_path(@gamer) and return if @gamer.handle != params[:id]
  end

And every action that needs it has the @gamer object loaded from the URL param, with 404 errors handled and mistaken case fixed. There’s a patch that will let you rename the :id parameter. I can’t say I mind if it’s not accepted; I don’t mind calling it :id instead of :handle or :name because I think of it as the public id of the object.

Come back Thursday, I’ll tell you how I made my discussion URLs even more useful.

If you want to get ready now, grab slash_urls.rb and drop it in your lib directory. At the top of your config/routes.rb, add the line:

 
require 'slash_urls'

And now all my URLs on NearbyGamers use slashes instead of semicolons. I only had one or two actions on my ActiveResource routes besides the built-in CRUD, so I’m not worried about doing a 301 redirects.