push.cx
Peter Bhat Harkins
Redirecting Users' URLs
I got an email in response to an old post on how I designed NearbyGamer’s discussion URLs. It asked how to create readable URLs for a community site where users might edit those URLs. What happens after users have made lots and lots of edits?
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.