Using URI Templates on XML Security Gateways

Earlier this fall, Anil John put out the following Twitter challenge:

“@Vordel, @layer7, @IBM_DataPower If you support REST, implement support for URI templates in XML Security Gateways”

Somebody brought Anil’s tweet to our attention this week, and Jay Thorne, who leads our tactical group, put together a nice example of just how to do this using SecureSpan Gateways.

URI templates are a simple idea to formalize variable expansion inside URI prototypes. A receiving system can then trivially parse out substituted components of the URI and use these as input. There’s an IETF submission here that describes the approach. It turns out that it was co-authored by my old friend and ex-IBM colleague Dave Orchard. Another co-author is Mark Nottingham, who I worked with at the WS-I. I guess I should have looked into this earlier. Sorry guys.

Here’s a real example of how URI templates work. Let’s begin with the template:

http://somesite/Template/{Noun}/{Verb}/{Object}

The braces represent variables for run time substitution. Suppose these variables equaled:

Noun=Dog

Verb=bites

Object=man

The result of the substitution would then be:

http://somesite/Template/Dog/bites/man

Which is pretty easy to parse up and process by a web application residing at http://somesite/Template

URI templates are also very easy to process on a SecureSpan Gateway. Here’s a policy that demonstrates how to access the variables in the URI. Basically, all this policy does is parse up the URI, audit the results, and echo the content back to the sender:

I’ll bind this policy to a particular URI range on my SecureSpan gateway virtual instance. This happens to be running with an HTTP listener on port 8080 on my Macbook Pro:

Now let’s walk through the policy in detail. The first assertion uses a regular expression to parse the URI.:

It places the content of the expansion variables Noun, Verb, Object into Vars[1] , Vars[2] and Vars[3] respectively. The next two assertions in the policy simply audit the resulting variables into the SSG audit subsystem; this can sink to cluster storage, or go off box. Finally, the policy populates a template XML document with the contents of the variables and echos this back to the original sender:

When I fire up my browser and hit the REST service http://scottssg:8080/Template/Dog/bites/man I get:

Obviously in a real policy, you would do something more interesting than just echoing parameters, such as route the message to a particular internal host based on template content. And you can certainly compose outgoing URIs using existing variable substitution capability in SecureSpan. The take away is this is very simple to implement, and I think that it highlights that here at Layer 7, we think that supporting RESTful services is just as important as supporting SOAP.