GoogleAppEngine:URLRewriting

URL re-writing is possible with Open Blue-Dragon on Google's App-Engine.

Contents 1 Pre-requisites 2 What is URL re-writing? 3 Why re-write URLs? 4 Implementation

Pre-requisites

OpenBD GAE version (obviously). Eclipse users will need to install Google's plugin (there is a command-line SDK also). Check out the getting started page for a deeper look at this: [1].

What is URL re-writing?

Simply put, it's serving up content based on a URL that indirectly references it. So, we create rules which tell us how to get from certain URL patterns to certain content. e.g. http://mydomain.com/page/1 could be made to serve up either a CFML module or a PDF file.

Why re-write URLs?

First off, would you rather see this:

   http://sub.domain.com/some/directory/module.cfm?loadArticle=374&publishDate=03_20_2009

or this:

   http://sub.domain.com/article/2009/3/20/374

More importantly, which of these is more robust? Which one can remain unchanged if we change the internal workings of the application? The second type of URL might be referred as SES, or Search Engine Safe, because of the latter reason mentioned. The outside world needn't know that I use a URL variable called loadArticle and, furthermore, I would like the liberty to change that in the future if needs be. Any user with some savvy can probably discern that the second URL is in year-month-day format and, if our application is friendly, can easily remember that pattern to access data they want to see. Custom URL patterns also disguise your web-application's implementation. More importantly, they allow you to present your API via URLs that are intuitive. Even if your web-service is for internal use only that makes for quicker development times.

Implementation

   Visit [2] and download the package there.
       there are two files of interest in this package: urlrewrite-3.2.0.jar (version 3.2.0) and urlrewrite.xml.

   Create a project with the OpenBD framework.

   Copy urlrewrite-3.2.0.jar into /war/WEB-INF/lib

   Copy urlrewrite.xml into /war/WEB-INF

You will need to add the following snippet to your web.xml:

	<filter>
		<filter-name>UrlRewriteFilter</filter-name>
		<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
	</filter>
	<filter-mapping>
		<filter-name>UrlRewriteFilter</filter-name>
		<url-pattern>/*</url-pattern>
	</filter-mapping>

...in order to enable the URL author. I added the code just below the first <listener> tag (below the opening web-app tag).

Now it's off to the races!

Open up urlrewrite.xml and you will see a slough of examples. Here is the XML I will explain:

	<rule>
		<note>Generic CFC redirect</note>
		<from>^/(.*)/(.*)/$</from>
		<to>/$1.cfc?method=$2</to>
	</rule>

	<rule>
		<note>Generic CFM redirect</note>
		<from>^(.*).cfm(.*)$</from>
		<to>/$1.cfm$2</to>
	</rule>

...here we have two rules. A rule corresponds to one URL pattern. In some cases your patterns may overlap; if so, you will need to carefully consider the order in which your rules appear. These rules can use simple wild-cards (*, ?) but the more powerful patterns will utilize regular-expressions. If you are unfamiliar with regular expressions then check out this site: [3]. For further explanation on the power of the tuckey re-writer (which is considerable) check out their documentation. You can do things like redirects and browser detection with it.

Note that in most regex engines a stored value is accessed via \1, \2, et cetera. Here we use the notation $1, $2, ... similarly.

The first rule: this maps from a URL like "/do/something/here/" to "/do/something.cfc?method=here". A URL pattern like this allows us to leverage the natural hierarchy of our components similar to the way we use dot-notation to invoke them directly, just without the cruft of file-extensions and URL variables exposed for all the world to see (and one more thing for us to remember every time we write a URL).

The second rule: this maps any URL ending in .cfm to a CFML page. We might like to just have a URL like "/page" map to "/page.cfm" but that conflicts the first rule as it is. Again, further consideration of the rules for your particular case is paramount. In this case the .cfm pages are providing a user interface while all of the heavy-lifting is done via direct method invocation and/or AJAX calls.