Proxy Base path proxy endpoint and API proxy differ

asharma377
Participant V

Hi I have a question on the base path. I have an option to add/change the base path in "proxy endpoint" under the head below...

<HTTPProxyConnection>  <BasePath>/apis/v1.0/customers/*/reviews</BasePath>

However, under the Navigator when i click on the proxy (name) i see read only information as below -

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<APIProxy revision="1" name="product-reviews-1_testAPIProduct">
<Basepaths>/productreviews</Basepaths>

I noticed that some of our proxies these values are different. This is different than the basepath mentioned in proxy endpoint.

During, api calls we are using the full path and it is working fine.

/apis/v1.0/customers/*/reviews

Will this cause any conflict at any further stage - deployment etc.

thanks,

aakash

1 8 1,247
8 REPLIES 8

It will not cause a problem.

The Basepaths claimed in the apiproxy.xml file will not be used when you import the proxy bundle. Instead Apigee Edge will inspect the bundle for proxy endpoints and the base paths used THERE.

It's a "bug" that these base paths are listed in the top-level XML file. Not necessary, and confusing.

If you like you can remove the line like

<Basepaths>/productreviews</Basepaths>

...from your top-level xML file.

thanks a lot..yes it's little confusing... 🙂

@Dino is this still a bug? I ask because we have a query to pull the revision.basepath[0] and happened to notice that in one case we saw an "incorrect" basepath. Apigee evidently uses the HTTPProxyConnection basepath.

As per Apigee 4.19.06 , that is there and doesn't impact any api bundle upload. I think you need to crosscheck your api revision and the query once.

There are multiple data sources . Let's be careful about which ones we're talking about. When you said

we have a query to pull the revision.basepath[0]

And I think you mean, you are using the Apigee admin API to query the proxy basepath. That information is valid and correct (or it SHOULD be, always). Actually it's not as simple as that - there are two things that Apigee has called "basepath" in a proxy bundle. One is the "basepath" that you configure statically in the ProxyEndpoint. And the other is the basepath you specify at the time you deploy the proxy bundle. The runtime basepath is a combination of the latter and the former.

An example.

If your proxy revision has a ProxyEndpoint with a BasePath of /foo and you deploy that revision, specifying a basepath of /bar, then the effective basepath of your API proxy revision will be /bar/foo .

The "deployment basepath" is a documented part of the Admin API, but it is not accessible through the Apigee Admin UI. If you use a CI/CD tool to deploy, you may be specifying a basepath other than / , and in that case you will have the effect I just described.

You said

happened to notice that in one case we saw an "incorrect" basepath.

I don't think "incorrect" is the most accurate term here. It's probably correct, unless there is a massive bug. Perhaps a better word might be "unexpected" ? Maybe you found an unexpected basepath there? If so, it possibly got there when you deployed the proxy revision.

The thing I mentioned in my comment from March 2018, the Basepaths element in the proxy metadata file (not the ProxyEndpoint file) .... is still there, and is still ignored. This is different than either of the other two things I just described.

Yes you're correct, Dino, we use the Mgmt APIs to compile a list of all our paths and we found one that was unexpected, and since have corrected. I will paste a few images from our Apigee Edge:

Overview tab shows deployment path ..printers/send (expected): overview.png

Develop tab manifest shows unexpected basepath ..printers/print: manifest.png

Proxy endpoint (same as deployment) proxybasepath.png

We were concerned when the API Management query for the revision showed the basepath ../printers/print, when we know it is deployed to ../printers/send


Is there a better method of retrieving a list of all our deployed proxies' basepaths? Thanks again!

Ignore the manifest. That does not get validated or used. I actually leave all of those blank in my proxies.

Querying the Mgmt API to "close the loop" and verify that the basepaths you are expecting are actually in use.... is a good approach. You want to query the proxyendpoints in the proxy revision. (Not the API Proxy bundle metadata, which as I said, is not used at runtime)

You can also perform healthchecks on the actual proxies.

I incorrectly called it the manifest. I would like to close this question down and open a new question that more properly addresses our issue.