If you are a Java developer (especially if you use the Struts framework), odds are that you don’t care about friendly URLs.  You probably don’t see anything wrong with URLs that look like /getUserInfo.do or /listUsers.do.  The URLs make perfect sense in a programming scenario as they explain exactly what operation needs to be performed…to a computer program. It goes without saying that humans don’t always think like a computer, hence the clean URL design pattern.

There are tons of articles describing the benefits of search engine friendly URLs, they mainly deal in the realm of optimizing for search engines, improving page rankings and making a nicer impression on the user.

As the core Struts framework was developed and implemented before clean URLs became en vogue, there wasn’t much thought put towards them.  At Gavant Software, we typically will use a web server like Apache in front of our Java applications.  I know we can use mod_rewrite in Apache, but that solution is not optimal.  First off, our developer environments don’t use Apache, so that presents a problem right away.  Second, you are tying business logic to a specific environment.  Maintaining several .htaccess files for multiple environments and keeping them all in sync will surely prove to become a disaster over time.

I finally came across a package that makes use of Struts’ filters.  The package is appropriately named URL Rewrite Filter.  We are exploring the 3.2 version, even though it says its still in beta.  You can check out the site to read up on it, but at first glance this seems to do everything we are looking for.  It keeps the URL logic in the application, it works in all environments and it is easy to maintain.

It is really easy to get started with this, I was up and running creating rules in about 10 minutes.  All it takes is loading a simple jar and an XML configuration file (just like everything else is Struts).  We are still exploring this package in our dev environments, we have yet to perform any serious testing.  I’ll report back after we run some before and after tests to see if application performance is affected in any way.