Making sense of API Product configuration  

An Apigee Edge API Product lets you restrict access to proxy resources based on some combination of proxies and resource paths. When you add a Product to a Developer App, you can use the keys generated for that App to enforce this restricted access.

When you create a Product, Edge lets you specify zero or more proxies and zero or more resource paths to define the "restrictions" you wish to achieve.

But wait, what does it mean if you do not specify any proxies? Or, if you don't specify any resource paths? Or, for that matter, if you omit both? This is a frequent source of confusion for Edge developers!

API Products 101

Here's a common Product setup. Let's say you have a proxy called StreetCarts, which lets you find information about local food carts. The basepath of this proxy is /streetcarts.

Now, let's say you want to allow access only to certain resources that the proxy knows about. You can do this by adding both the proxy and the resources you wish to allow to an API Product. For example, here's what the Product UI would look like, where the resource paths /reviews, /carts, and /menus are listed and the proxy StreetCarts is specified:

Using an API key from a Developer App associated with this Product, the following call will succeed (assuming ABCD is a valid key and the VerifyApiKey proxy is used in the proxy). It succeeds because the basepath of the StreetCarts proxy is /streetcarts and both the proxy and the resource path /carts are in the Product:

GET /streetcarts/carts?apikey=ABCD

But this will fail, because the resource path /users is not in the Product:

GET /streetcarts/users?apikey=ABCD

This also fails, because the basepath of the proxy StreetCarts is not /foodcarts:

GET /foodcarts/carts?apikey=ABCD

The following path fails as well since the basepath by itself is not allowed in the above configuration. If, however, you do want to allow the basepath, one option would be to add "/" to the list of resources in the product, which (by default) allows the basepath and all subpaths to go through.

GET /streetcarts?apikey=ABCD 

To learn more about how to allow or exclude resources based on wildcards, see Configuring the behavior of a Resource Path of '/', '/*', and '/**'.

Be careful when omitting proxies and/or resource paths

Now, what happens if you omit proxies and/or resources from the Product? You need to be aware of potential risks with these kinds of setups!

When you specify resource paths but omit proxies

If you include paths in the Product, but do not specify any proxies, then keys associated with the Product will work for ANY proxy; however, requests will only succeed for the given paths. Consider the following configuration:

Given this setup, this hypothetical call will succeed:

GET /basepath_A/accounts?apikey=ABCD

And so will this!

GET /basepath_B/accounts?apikey=ABCD

The basepaths don't matter, because no proxies are specified in the Product. So, any proxy basepath will be a potential match for the given key. However, proxy requests will only succeed if a valid resource path is given. For example, this call will fail because /carts is not specified in the Product.

GET /streetcarts/carts?apikey=ABCD

When you specify proxies but omit resource paths

If you specify one or more proxies, but no resource paths, then your API key will work with ALL RESOURCE PATHS in the specified proxy(s), including just the basepath.

The following API call will succeed:

GET /streetcarts/carts?apikey=ABCD

The following call will also succeed because all paths, including the basepath, for the StreetCarts proxy are allowed:

GET /streetcarts?apikey=ABDC 

However, this will fail, because the basepath for the specified proxy (StreetCarts) is /streetcarts, not /foodcarts:

GET /foodcarts/carts?apikey=ABCD

No proxies, no resources: Beware the skeleton key option!

A skeleton key is a key that opens any lock in your house. If you create a product with NO proxies and NO paths, then the key associated with that product can be used with ANY key-protected proxy in your org. In the UI, such a configuration would look like this:

This option may be useful for testing, or for very specific use cases. But be sure you understand the effect of creating a Product with no proxies or paths. Skeleton key!

You can read more about creating products in the Edge documentation.