IanG on Tap

Kevin Jones illustrates precisely why it is that you really don't want file extensions in your URLs.

Kevin's old RSS feed was JSP-based. The new one is still Java-based, but he's moved over to an MVC approach. Because his URLs reflect these kinds of internal implementation details, it means the URL for his feed changed when the implementation changed - it now uses a .do extension instead of .jsp. As he points out, this leads to versioning problems in the long run. If you make sure your URLs never expose these details in the first place, you can avoid these problems, which is why I went to the great lengths partly described here and here.

If Kevin decides to go down the same route, I hope for his sake that it's easier in Java than it was in ASP.NET!

Since he asks for "any better ideas", and in those previous articles I only described the ASP.NET-specific parts of what I did, I'll briefly outline the more technology-agnostic aspect of how I deal with this here. And rather than just email this to Kevin directly, I thought it might be of broader interest, hence this blog entry.

What I Did

I've written a simple content management system for my site. The content and structure of the site is mainly stored inside a SQL Server 2000 database. The only things on the web server's disk are static content (mostly images and downloadable files), the .aspx templates that present the content in HTML form, and the compiled code for the web site.

There's a table in the database describing the hierarchy of the site. Each item corresponds either to a page, or in certain cases a handler that generates a whole collection of similar pages. (My blog is an example of the latter. Because all of my blog entries are essentially the same page but with different content, there is just one entry in the site hierarchy table for the http://www.interact-sw.co.uk/iangblog/ URL and everything under it. This actually maps to an IHttpHandler implementation. (That's the ASP.NET equivalent of a Servlet, Kev.) That handler then examines the remainder of the URL (e.g. "/2004/01/") and decides which of the various .aspx pages to use (item, day, month, year, or recent, depending on how much of the tail is present) and internally forwards the request onto that page, placing the necessary content in the request scope so that the page can then present that content.)

Each item in the site hierarchy table has a foreign key into the templates table. The templates table contains the internal URL. For simple pages, this will be the path to the relevant .aspx template, e.g. /templates/code.aspx for pages containg nothing but source code. (Note that you can't hit these template URLs from the outside - these URLs are entirely internal to the site. You'll get a 404 if you try. Right now I'm not bothering to generate any content for the 404 though, so what you see will depend on your browser. For Internet Explorer, it shows its normal error page. Mozilla Firebird does something a little more eccentric.) The blog's template is just /BlogHandler, and my web.config file maps that internal URL onto the blog HttpHandler.

This makes it easy to change the implementation without changing the public URL. If for some reason I decided to move over to a .ashx file for my blog handler, I would only have to change the entry in the templates table. That would have no impact on the public URL - that's determined by the site hierarchy table.