Alex Le

While working on the next generation site at Yellowpages.com (being built on Ruby on Rails), I’ve had numerous opportunities to look into the innerworkings of the framework. One major point of frustration for me so far has been what seems like an arbitrary constraint of the framework in the URL Routing code. Jamis Buck has done an outstanding job of explaining a lot of the “magic” behind routing, but he has glossed over the important subject of adding query parameters to the URL. While most simple applications built in rails can get away with storing lots of state in the session and the URL path, we can’t do that at Yellowpages.com. One of the goals of our next gen site effort is to make our application as stateless as possible. It might be naïve to assume that we can accomplish this goal, but so far, the constraint has made us more creative, and our application more responsive to high load. Because of the stateless nature of our current prototypes, storing application state in the URL path has become too difficult, and we will be instead storing a few key pieces of data in the URL via query parameters. Unfortunately, in Rails, if you are using keys for your query parameters that have previously been used as significant (path based) keys on your other routes, Rails will happily omit the query parameter key/value pair altogether. I think (after looking at the code) that this was a design consideration and not a bug, and I’ve probed the Rails mailing list, and Jamis himself for an answer as to why this is necessary. Hopefully any workarounds that I post here later will solve the problem elegantly, or Jamis/the rails community will convince me that its not a problem at all.