For years, APIs and services have been around in enterprise computing. In the good old middleware days, service-oriented architecture came to existence and services were exposed using SOAP web service APIs. These APIs were mainly used to integrate applications to legacy systems and to one another.

With the advent of cloud and mobile and the need for massive internal and external adoption of services, REST-based APIs have replaced SOAP web services. REST APIs are HTTP-based, lighter, and easier to understand and integrate and therefore have become the defacto standard for creating enterprise APIs. Enterprise APIs can be internal APIs (i.e., APIs within or across LoB) and as well as for external APIs (i.e., APIs for partners or third-party developers).

In the past few years, enterprises learned from web-scale consumer APIs and realized that in order to create an ecosystem of applications around your API, there is more than just creating an API and expecting consumers to use them, be it internal or external.

Enter API Management

API management is the ability to document, publish, share, control, consume, and monitor the consumption of APIs. All of this is done in a fashion that allows for easy publishing and onboarding of developers using APIs.

So, the question is, if an enterprise is looking to publish internal and/or external APIs, is there a difference in managing them? The majority of enterprises consume more internal APIs than external ones. API management is essential for both internal as well as external APIs as long as there is a need for:

• Providing an easy means to manage the lifecycle of APIs (create, publish, version, and retire).

• Secured access for protecting sensitive data that is being exposed.

• Differentiated access while allowing the consumption of APIs among stakeholders.

• Easier on-boarding of applications and developers that consume the APIs.

• Monitoring of real-time access and usage trends of APIs and take actions as required by the business.

So, how do you begin with API management? What we see is, depending on the maturity of the enterprise, the journey of API adoption can vary. Some enterprises with no APIs will start with internal APIs, get the ball rolling, work closely with internal stakeholders to fine tune the APIs, and then roll it out for external consumption. On the other hand, mature enterprises may start directly with external adoption. Some may just roll out internal APIs depending on the business need. Let’s take a look at differences in the requirements when it comes to publishing and consuming APIs.

Platforms that provide a unified approach to rolling out internal and/or external APIs can better facilitate enterprises willing to develop an ecosystem around their APIs.