Product Configuration: Resource Path vs. API Proxies

[#1]

I'm a little confused on the relationship between Resource Paths and API Proxies within the API Product configuration.

Lets say I have 2 pass-through poxies defined with the following base URLs:

Proxy 1: catalog_productsAPI -- /v1/catalog/products

The following are valid within this API:

/v1/catalog/products/

/v1/catalog/products/search

/v1/catalog/products/skus

Proxy 2: user_profilesAPI -- /v1/user/profile

The following are valid within this API:

/v1/user/profiles/

/v1/user/profiles/addresses

/v1/user/profiles/favorites

Again these are pass through; that is there are no flows that are defined within any of the Proxies. Everything that targets a base url will simply be forwarded onto the the target.

If I decide to create a product with {catalog_productsAPI, user_profilesAPI}

can I use the resource paths to constrain what URIs are valid. For example, I want my product to only respond to:

/v1/catalog/products/skus --> set up resource path as: /skus/**

/v1/user/profiles/favorites --> set up resource path as: /favorites/**

And if I do this, then how does Apigee know which API_Proxy to forward the request to?

Do I need to include the baseURL in my resource path configuration as well?

thanks

Zameer

[prabhup1 · Accepted solution]

@Zameer Andani - See if this post answers your question - https://community.apigee.com/articles/38309/making-sense-of-api-product-configuration.html.

[prabhup1 · Accepted solution]

@Zameer Andani - See if this post answers your question - https://community.apigee.com/articles/38309/making-sense-of-api-product-configuration.html.

[willwitman · Accepted solution]

Hi @Zameer Andani

I recommend reading this article "Making sense of API Product configuration", which may answer your final two questions which relate to how products work.

This may also help:

1. The information in a product is used when you have a VerifyAPIKey or OAuth policy attached to the request flow of a proxy. These policies enforce the “restriction” of API calls using keys or tokens that are tied to a product.

2. When these policies execute, Edge looks at the request path and determines if it matches any combination of base paths and/or resource paths in the product associated with the key or token that is present in the request. Another way to put this is that Edge tries to match the request path parts with the logical ANDing of any of the combinations of base paths and resource paths in the product.

For example, if the product specifies a base path of /v1/catalog/products, and a resource path of /skus/**, then a request of /v1/catalog/products/skus/12345 will be a match. But /v1/catalog/products/search will not be a match. I hope this helps.

[#5]

thanks. makes perfect sense. This probably explains why we add the VerifyAPIKey policy as a PreFlow activity.