Using an API

Most medium to large companies nowadays produce likely hundreds or thousands of APIs, whose purpose is to be of use to developers across teams and departments, but also to partner developers and beyond. APIs have become, after all, the primary means of communication between computer applications within most enterprises.

The ubiquity of APIs means that a world of information and computation is potentially at the developers’ fingertips. However, this also poses its own set of challenges: most notably, access control.

Adding more users to an API Ecosystem, such as employees, partners, vendors, and in some cases even customers, means that controlling who consumes APIs becomes fundamental within a well-structured API Management Program, which must therefore include an effective API security strategy.

Access Control

As an enterprise, there are two major reasons for not giving universal access to your APIs, both publicly, but also within the company and its partners.

Security is of course the first and most important aspect to consider to safeguard your enterprise’s assets. Not everyone should have access to all enterprise data and computation. To achieve this, most companies use an API Gateway, which allows access to certain APIs only to authorized consumers.

Gateways provide also another useful functionality, and the second reason why Access Control is so important: usage policies. It is not only critical to make sure the consumer is an approved, trustworthy one, but also that they won’t overload the system that provides an API.

What is an API Consumer?

Consuming an API means having the authorization to make requests to that API. But who is actually being authorized? It is not the users themselves, but their Applications. After all, APIs are the means of communications between programs, not individuals.

Considering Applications as Consumers of APIs should also highlight the necessity of APIs to be easily accessible, as any successful product ought to be for its consumer. (Read more about why you should handle APIs like products here.)

Streamlining Access Control

Usually, when developers need to request access to an API, they need to communicate their request to someone, likely a product owner. They will first need to check the request (often as informally as with an easy-to-miss email), then approve the request, and engage someone responsible for configuring the API Gateway to finally give the consumer Application access to the API. This is not only a slow process, but often enough it is managed without much structure.

An API Ecosystem where consuming an API requires you to go through hoops to finally start using it is without a doubt a hindrance to developers, and a limitation for productivity.

The solution? Make access control quick, simple, and traceable. No more email requests, chats, or dedicated meetings, and, most importantly, no need for manual configurations on the Gateway. Access to APIs should be streamlined with a simple formal procedure that can be resolved quickly, both to grant access to an API, and also to revoke it.

This procedure represents the signing of a contract between API and Application, and, as such, its history should also be easy to consult for optimal transparency. Let’s see how this is all managed in ApiShare.

A Contract between API and Application: The Subscription

ApiShare provides you with a single point of reference to govern the relationships between all your enterprise’s APIs and Applications. The contract that embodies each such relationship in ApiShare is called a Subscription.

When a developer needs to grant their Application access to an API, all they need to do is make a Subscription request to it.

The Subscription form requires the developer to declare their consumer Application, as well as the destination environment of the API. (Access to different environments is determined by the user’s permissions.) Furthermore, the Subscription must include some estimate of the traffic their Application will generate.

Last, the developer can optionally provide a set of use-cases for which their Application requires access to the API, before submitting the request.

The API owner will then be notified of the request, and they’ll be able to easily assess the request, and approve or reject it with some comment.

Once the API owner accepts the request, ApiShare will integrate with your Gateway (if configured) to set everything up automatically, without any manual intervention on the gateway, thus activating the Subscription.

An active Subscription can then be quickly found, suspended, and eventually revoked once the consumer Application no longer requires it.

Last but not least, a history of the subscription will always be available to keep track of the contract’s full journey and activity.

Making API Management simple

In this post we’ve seen how streamlining access control to enterprise APIs can make engaging developers much faster and more agile. Check out our blog to find out how ApiShare also simplifies API Discovery and Governance, and feel free to contact our team if you want to learn even more about ApiShare.