Matching a flow with or without a trailing slash

Not applicable

Some of our users have pointed out that our APIs do not support trailing slashes between the method and the query parameters. For example, we APIs such as

https://api.sandbox.amadeus.com/v1.2/flights/extensive-search?apikey=myapikey&origin=BLR

which are supported by a /flights proxy that has flow matching conditions like

<Flow name="extensive-search">
  <Description>Extensive Search</Description>
  <Condition>(proxy.pathsuffix MatchesPath "/extensive-search") and (request.verb = "GET")</Condition>
  <Request>
    <Step>
      <!--- STUFF HAPPENS HERE --->
    </Step>
  </Request>
  <Response/>
</Flow>

The Request steps on this flow are not executed if the user makes a (perfectly legitimate) call to

https://api.sandbox.amadeus.com/v1.2/flights/extensive-search/?apikey=myapikey&origin=BLR

This is implicitly supported by the backend Apache Camel, Wildfly and Django-Rest servers we use.

I took a quick look on the internet and found I'm not the only one with this question

http://stackoverflow.com/questions/28526364/apigee-proxy-with-trailing-slash

however the approach of adding an OR to cope with this out-of-the-box kinda sucks. After reading the documentation I also tried using LikePath instead of MatchesPath, but this didn't seem to deal with the issue either.

Is there a smart, easy way to support the trailing slash?

Solved Solved
1 2 1,733
1 ACCEPTED SOLUTION

You can use a regex in the Condition, eg

<Condition>(proxy.pathsuffix ~~ "/extensive-search/?") AND (request.verb = "GET")</Condition>

The ~~ implies a regex match. Regex = Regular Expression. The trailing question mark in the string means "zero or one of the previous". The previous is a slash. So the regex should work for your purposes.

View solution in original post

2 REPLIES 2

You can use a regex in the Condition, eg

<Condition>(proxy.pathsuffix ~~ "/extensive-search/?") AND (request.verb = "GET")</Condition>

The ~~ implies a regex match. Regex = Regular Expression. The trailing question mark in the string means "zero or one of the previous". The previous is a slash. So the regex should work for your purposes.

Yup, that's clean and it works, thanks DIno! The only weird thing is that the resources are now no longer displayed on the API proxy summary screen, that's OK for me since I'm working from the XML but it might be a bit confusing for less technical admins