We’ve glossed over it a bit in previous posts on API development, but there are two concepts that are critical to any APIM implementation – Products and Subscriptions.
Together, Subscriptions, Products, and APIs form the backbone of your API implementation.
Subscriptions
Subscriptions define what you have access to by the keys that are generated. In the below screenshot, you can see I have a Primary and Secondary Key that I can use to connect to the Product called “Contacts”
In this case, the scope of my subscription has been configured to Product. I could configure it to a specific API or to all APIs as alternative scopes if I wanted it to. I generally prefer to keep the scope set to Product as this keeps things consistent and allows me to manage API access at the Product level.
You’ll also notice a checkbox for “Allow Tracing” that lets me enable tracing, via my API calls, when testing.
The Subscription keys (primary or secondary) are the values supplied in the header Ocp-Apim-Subscription-Key when making a call to get your data.
Products
Products are where the magic of APIM starts to happen. The best way to think about products is that they are a collection of your APIs along with any overseeing code, grouped into a structure that you want to offer users.
In the scenario where I might have APIs on Contacts, Accounts, Users, Opportunities, and Services, I might create a product called ContactManagement that encompasses Contacts, Users, and Accounts as APIs related to that product.
In addition, with Products, I can perform the following actions;
- What APIs are accessible?
- Evaluate base policies (i.e., connections, throttling)
- Assign Subscriptions, see where they are used, and enforce a valid subscription to exist
- Identify if the Product is in a Published State
When a Product is unpublished, it can still be used. It’s only when the product has been Published that it will appear in the Developer Portal for users to validate.