how to match regardless whether there is a trailing '/' on the url when you define a resource in api proxy

I have an issue while defining a resource in my api proxy.

I want to allow only POST requests if the path suffix is /applicationDetails or /applicationDetails/

Sometimes users hit the url as /applicationDetails/, it doesnt go through the conditional flow in this case, although i would want it to go through

I tried defining as /applicationDetails* it had no effect.

I got through a workaround by manually changing the condition as

<Condition>(proxy.pathsuffix MatchesPath "/applicationDetails") or (proxy.pathsuffix MatchesPath "/applicationDetails/") and (request.verb = "POST")</Condition>

Is this the best way?

Solved Solved
6 7 10.1K
1 ACCEPTED SOLUTION

Dear @Nagashree B ,

Apigee conditions supports regular expressions JavaRegex , you can use below one too. For more details refer Condition Reference Doc here.

<Condition>(proxy.pathsuffix JavaRegex "/applicationDetails(/?)") and (request.verb = "POST")</Condition>

If you would like to match against path only then you can extract path segment into a variable and compare against that variable in above conditional flow. For more information look at Extract Variable Policy specifying patterns with multiple variables.

Cheers,

Anil Sagar

View solution in original post

7 REPLIES 7

Dear @Nagashree B ,

Apigee conditions supports regular expressions JavaRegex , you can use below one too. For more details refer Condition Reference Doc here.

<Condition>(proxy.pathsuffix JavaRegex "/applicationDetails(/?)") and (request.verb = "POST")</Condition>

If you would like to match against path only then you can extract path segment into a variable and compare against that variable in above conditional flow. For more information look at Extract Variable Policy specifying patterns with multiple variables.

Cheers,

Anil Sagar

To answert the question - "is this the best way?" My answer is "maybe". It's perfectly readable and it works, so why not use it? Regex (aka regular expression matching) is another option and is perhaps more flexible.

If using regex, then I suggest that you include the string terminator in the pattern. This will let you match only when the pathsuffix is /applicationDetails or /applicationDetails/ but not /applicationDetails/something .

The suggested regex ( "/applicationDetails(/?)" ) will allow a slash, or maybe not, followed by anything at all. It will match even /applicationDetailsAreLovely .

A more restrictive regex with the terminator is "/applicationDetails(/?)$" . This would prevent matches on /applicationDetails/something and /applicationDetailsAreLovely

Actually /? means zero or one slash and it won't allow /something at the end, no need to add EOL.

Great thread, all. Thanks for asking, Nagashree. FYI that I've added a link to this from the docs, in both the Conditions reference and API resources and conditional flows topics.

Not applicable

The regex is a great feature but for your case this might be a simpler solution

<Condition>(proxy.pathsuffix ~~ "/applicationDetails(/?)") and (request.verb = "POST")</Condition>

-- Doh - just realized that this is exactly the same solution - the ~~ being shorthand for JavaRegex!

Based on REST best practices

Open API Specification with required Docs should clear the user about usage of /applicationDetails instead of /applicationDetails/

Does /applicationDetails and /applicationDetails/ represent different resource ?

from REST perspective. Its more of educating the user, is that correct approach ?

Reason : /applicationDetails will result in collection Vs /applicationDetails/ used only when representing specific details

It's probably bad form to allow request URLs with a trailing slash. It's bad aesthetics in my opinion. But some people have clients that append the trailing slash. As described above, You can handle it with a regex match in the Apigee Edge flow condition.