Path within curly braces work similar to and asterisk(*)

[veldurthy-venka]

Is the usage of curly braces a correct usage with apigee instead of using asterisk(*).

eg: proxy.pathsuffix MatchesPath user/{userId} is that a valid apigee syntax or proxy.pathsuffix MatchesPath user/* the later is given in documentation. Is user/{userId} also a documented way of usage within apigee?

[dchiesa1]

No, it is not documented to use a pathname within curly braces in a Condition element.

There is a way to use that expression in ExtractVariables. (specifically for use with URI Paths).

Check the documentation for more details.

There are reference pages for the Condition syntax and for the ExtractVariables policy.

[rcooper3]

May I clarify, proxy.pathsuffix MatchesPath user/{userId} does have a similar effect to proxy.pathsuffix MatchesPath user/* ?
However, is it not documented and therefore not reccomended/supported.

[dchiesa1]

proxy.pathsuffix MatchesPath user/{userId} does have a similar effect to proxy.pathsuffix MatchesPath user/* ? However, is it not documented and therefore not reccomended/supported.

AFAIK no, what you described does not work, and, there is no such documented capability.

Here is what I meant:

• if you want to match a path, then use the path-matching patterns like proxy.pathsuffix MatchesPath "/user/*"
• If you want to extract a segment from a path, then use the ExtractVariables policy.

It would be kinda neat to extract the segment from the path, implicitly, using a MatchesPath, something like what you can do with nodejs and the express module which will set req.params. But that is not supported in Apigee at this time.

[Naveen_Singh2]

We have been using curly braces in the resource path since a very long time. It seem to work similar to a wildcard (*). The reason for using the curly braces is  for teams to indicate its a dynamically generated value/id type while building the proxy. 

I agree with @dchiesa1 that to get the run time value ExtractVariable policy can be used. 

@dchiesa1 could you confirm that there wont be any support issues for such implementations( for the above use case)?