HTTP Path variables with the Axway/Vordel API Server

I've written about this before, but here's a recap and an extra trick which might be useful...

Let's say your API is expecting parameters passed in the URL, like so:

/customer/12345?name=test

Many REST APIs are defined like this, including parameters in their path. Here is how you'd read the value of the second item in the URL path, i.e. "12345" in this case.

Firstly, you'll need the Vordel API Server, which you can download from www.vordel.com . Then, create a new policy in Policy Studio, starting with the "Extract REST Request Attributes" filter. To do this, drag it onto the blank canvas of a new policy, then right-click on it and choose "Set as start". The purpose of this filter is to take the various REST request parameters and place them into variables (or "attributes") for you to use.

Next, join this using a green arrow to a "Trace" filter. The Trace filter serves a very useful purpose by tracing out the values of the variables which were created in the Extract REST Request Attributes filter. Notice that, by default, this filter traces out at the "DEBUG" level. This means that you'll only see the output if you're running the API Server at "DEBUG" level. You can change the trace level using the Vordel Manager interface (over SSL to port 8090, by default) under the "Settings" tab, as shown below:

Now, map this policy to a path called "/customer". The API Server matches on a "longest first" basis, so this means that "/customer/12345?name=test" will be caught by the "/customer" mapping.

Now run it with test traffic from a browser, and take a look at the tracing information in the Traffic view of the Vordel Manager interface (over SSL to port 8090, by default). You should see something like this:


Notice that the path value is clearly visible. ${http.path[2]} is the variable containing our URL parameter, which is "12345".

I can now output this, using a Set Message filter containing the following text:

Customer is ${http.path[2]}

I use a Content-Type of text/html since I'm returning this to a browser.

Then, when I connect to the API Server on the path of /customer/12345?name=test , I see the response "Customer is 12345".

Here is a screenshot of my entire policy. You can see that I placed a "Reflect Message" filter at the end, to return back the response to the client with a 200 HTTP status code:


You may notice above that the third filter is red. This is because Policy Studio does not know in advance about the existence of the ${http.path[2]} variable, so it flags this as a "missing" input variable to the "Return Customer ID" filter.