Combining words and wildcards in API proxy base path

[#1]

Hello Apigee Community!

I have 4 backend API endpoints:

• /a/foo
• /a/foo.json
• /a/foo.xml
• /a/bar

Preferably, I would like to configure 3 proxy endpoints in Apigee:

• /a/foo/
• /a/foo.*/
• /a/bar/

Unfortunately, /a/foo* and /a/bar belong to completely different API proxies so I cannot put them in a single one.

In ticket https://community.apigee.com/questions/7404/can-wildcards-be-used-in-basepaths.html Dallen points that "the wildcard must be a full path element for the classification engine to work as expected".

Do I understand it correctly that I cannot combine words with wildcards in a single base path element (to get sth like /foo.*/)?

The most obvious workaround is to go with 4 proxy endpoints (for /foo, /foo.json, /foo.xml and /bar). However, if I would like in the future to add a new type in my backend, let's say binary, I would have to add another proxy endpoint (/foo.bin). Am I correct?

Thank you,

Andrzej

[anilsr · Accepted solution]

@AndrzejDev ,

Very Interesting Question,

I have created two API Proxies with different base paths & different Target Endpoints.

• /a/* -- Points to Target -- /a -- will be used for /a/foo , /a/foo.json, /a/foo.xml, /a/foo.bin
• /a/bar -- Points to Target -- /a/bar

It works & classification happens as expected. @arghya das would you like to throw some light how exactly it happens even though request /a/bar also matches /a/* it hits /a/bar proxy instead /a/* ?

@AndrzejDev ,

You can have two API Proxies one with basepath /a/* & other with basepath /a/bar. Please find sample proxies that worked for me.

mockapi-rev1-2016-05-23.zip

mockapi2-rev1-2016-05-23.zip

Similarly , you can also have 3 proxy endpoints,

/a/foo , -- Points to Target -- /a/foo -- will be used for /a/foo

/a/* , -- Points to Target -- /a -- will be used for /a/foo.json, /a/foo.xml, /a/foo.bin

/a/bar, -- Points to Target -- /a/bar

[anilsr]

How about having a single API proxy with base path as /a or /a/* & route the traffic using route rules with two target endpoints /a/foo & /a/bar ?

[#4]

Hi @Anil Sagar! Thanks for your answer. Unfortunately I cannot put /a/foo and /a/bar in a single API proxy (business reasons).

[anilsr · Accepted solution]

@AndrzejDev ,

Very Interesting Question,

I have created two API Proxies with different base paths & different Target Endpoints.

• /a/* -- Points to Target -- /a -- will be used for /a/foo , /a/foo.json, /a/foo.xml, /a/foo.bin
• /a/bar -- Points to Target -- /a/bar

It works & classification happens as expected. @arghya das would you like to throw some light how exactly it happens even though request /a/bar also matches /a/* it hits /a/bar proxy instead /a/* ?

@AndrzejDev ,

You can have two API Proxies one with basepath /a/* & other with basepath /a/bar. Please find sample proxies that worked for me.

mockapi-rev1-2016-05-23.zip

mockapi2-rev1-2016-05-23.zip

Similarly , you can also have 3 proxy endpoints,

/a/foo , -- Points to Target -- /a/foo -- will be used for /a/foo

/a/* , -- Points to Target -- /a -- will be used for /a/foo.json, /a/foo.xml, /a/foo.bin

/a/bar, -- Points to Target -- /a/bar

[#6]

Hi @Anil Sagar,

thank you for your answer!

Your solution works perfectly. It is really good that there is a possibility to have "general" endpoint with wildcard and if needed, you can add specific paths.

Regards,

Andrzej

[anilsr]

@arghya das , Would you like to throw some light how exactly it happens even though request /a/bar also matches /a/* it hits /a/bar proxy instead /a/* ? Just would like to make sure this works as expected.

[adas]

@Anil Sagar I don't think this would be guaranteed to work when you have multiple endpoints like /a/xy, /a/pg and /a/*

We do have some best match logic in the request classification but I don't think wildcard and multiple endpoints matching the wildcard would work reliably. I would test it out and let you know my findings. For now, I would not suggest using this approach. I would rather suggest using the approach I mentioned in my earlier post about transforming the path between request and target.

[anilsr]

Thanks @arghya das , Looking forward to your findings. @Andrzej , You might need to hold on before we find out what exactly happens behind the scenes.

@archendra @Dino @Mukundha Madhavan @sribalaji @tskumar@apigee.com @Carlos Eberhardt What do you think about this scenario ?

[anilsr]

@arghya das If we can prove actual path has higher priority over wildcard basepath above solution might be useful. Looking at classification logic might throw some answers. Agree with you, Route Rules & Single Proxy / Target URL rewrite is the way to solve these issues ideally.

[adas]

@AndrzejDev I am guessing the /a/foo, /a/bar and other urls that you specified are backend urls. If that's the case, you need not have the same basepath in your proxies. You can always do url rewrite to transform the request basepath /xy to /abc/123 using assign message or javascript.

You can have 2 api proxies with different basepaths like /v1/req1 and /v1/req2 and tranforms them into the corresponding backend urls. Please refer to this article for transforming request url to target.

[#12]

Hi @arghya das,

thanks for your comment! You are right, but unfortunately these endpoints are currently used by customers (we are in the process of migration from another API management system) so we have to keep them as they are.

Could you share some knowledge regarding the solution that was suggested by @Anil Sagar , please?

Regards,

Andrzej

[adas]

@Andrzej Like I said, its not a recommended approach. I will give you one very simple example. In your case, say the /a/foo is undeployed for whatever reason and the /a/* proxy is still deployed. In such a case, all incoming requests would be served by the /a/* proxy due to the wildcard match. This would give unexpected results and cause issue with your api clients.

I am doing few more tests to see if this can be used as a reliable solution. I will keep you posted. I also need to check if the order of deployment of these proxies have any bearing on the runtime behaviour. So far it looks fine but I would be very careful about using this feature since its not something we 'officially' support and if the behaviour changes in the future your proxies would not longer work. I will keep you posted on my findings.

[#14]

Thanks @arghya das for the very clear example. Now I see the risks connected with having such configuration.

Looking forward to hearing the results of your tests!

Regards,

Andrzej

[adas · Accepted solution]

@AndrzejDev my tests turned out quite well. I tried with 3 proxies: /apigee/v1, /apigee/* and /apigee/v2. I could hit each of them uniquely as long as the path was deterministic. When I undeployed /apigee/v1 I could see the /apigee/* proxy getting hit. Apart from that most of it worked fine. I made sure the sequence in which you deploy them doesn't matter as long as the wildcard is deterministic. So you might be good with this.

Do you also have a scenario where you want to use /apigee/*/test/*. I am not sure how that would work.

[anilsr]

@arghya das , Above tests are mostly trial & error if I am not wrong. Do we have any classification logic to give higher priority to absolute paths than wild cards ? That will make the solution solid.

[#17]

Thank you for your support @arghya das! Fortunately, I I will not need more advanced scenarios like /apigee/*/test/*.

Regards,

Andrzej