API Specification Versioning against API releases,How to restrict customer to use specific release

for e.g

i have 10 release cycle and in each cycle im adding new features and the spec contains all the features.

my use case:

I have one API Specification which contains all features.

some customer can get only few features from spec but not all so how do i restrict some customer to use new features from single spec.

if any versioning possible or any other method which can help?

1 2 450
2 REPLIES 2

some customer can get only few features from spec but not all so how do i restrict some customer to use new features from single spec.

Hmm, well this is an interesting API publishing challenge.

I see a couple options.

  1. Today you said you have just one specification which contains all features. If you relax that, and provide different versions of the specification, then... the specification serves as the documentation of what is possible, and or valid with a given version of the API. Then you can create API products that wrap proxies which implement those various versions of the spec. And API Product authorization checks (VerifyAccessToken or VerifyApiKey) will automatically ensure that the calling app has the authorization to use the feature.

    In practice: Spec-v1 and Spec-v2 can correspond to Product1 and Product2. It's up to you to insure the proxy wrapped by these Products *enforces* the feature check. Then client app A can get credentials for Product1 , client app B can get credentials for Product2. When the client app sends a token or key, Apigee Edge will automatically associate the token or key to the product, and will check that it's valid.

  2. Keep one version of the spec and multiple API Products. Construct a separate human-language document that describes which features each API Product allows. Here again you need to have some way of enforcing the feature restriction .

Both of these suggestions rely on an underlying enforcement logic in your API Proxies. Either you need to duplicate your API Proxies, and map them 1:1 to each API Product, OR, you can use a single API Proxy that contains some smarts that enforces the product-to-feature mapping.

The single API proxy approach feels easier to me. I'd use the custom attributes on the API Products to specify the features that the product supports. (This is just the kind of thing the custom attrs on an API Product are designed to support.) The custom attr would have a key name of "supportedfeatures" or something like that, and the value of that custom attr would be a space-separated list, something like this:

feature1 feature2 feature3

Then use a custom JavaScript step to verify the feature requested is authorized by the product.

Let's assume you use OAuth tokens. Inside the common API Proxy, the policy sequence would be

  • VerifyAccessToken
  • JS-VerifyFeature

The JavaScript would be able to get the feature set for the Api product by reading the context variable 'apiproduct.supportedfeatures' . The JS would also be able to read the inbound url path, the query parameters, etc.... even the time of day, and then make a decision whether to allow the call given that set of inbound.

The JS can throw an exception to signal that the request is disallowed, and then you can use a FaultRule to handle that and issue an appropriate response.

@Dino-at-Google Thank you so much for the reply, i will test this feature and reply back to you