Over a million developers have joined DZone.

HTTP Path variables with the Axway/Vordel API Server

DZone's Guide to

HTTP Path variables with the Axway/Vordel API Server

· Integration Zone
Free Resource

Today’s data climate is fast-paced and it’s not slowing down. Here’s why your current integration solution is not enough. Brought to you in partnership with Liaison Technologies.

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:


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.

Is iPaaS solving the right problems? Not knowing the fundamental difference between iPaaS and iPaaS+ could cost you down the road. Brought to you in partnership with Liaison Technologies.


Published at DZone with permission of Mark O'Neill, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}