For years, APIs and Services have been around in Enterprise Computing. In the good old middleware days, Service Oriented Architecture came into 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, mobile, and the need for massive internal/external adoption of services, REST-based APIs have replaced SOAP Web services. REST APIs are HTTP-based, lighter, easier to understand, and integrate, and therefore, have become the de facto standard for creating enterprise APIs. Enterprise APIs can be internal APIs i.e. within or across LoB (Line of Business), or external APIs for partners and third-party developers.
In the past few years, enterprises, having learned from web-scale consumer APIs, realized that in order to create an ecosystem of applications around your API, it takes more than just creating an API and expecting consumers to use them. This is true for both internal and external APIs.
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 easy publishing and onboarding of developers using the 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,
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,
|Creation of APIs||APIs are created based on custom business logic and could be auto-generated during the application development process.||APIs are tuned and designed as per the needs of the external partners and third-party developers.|
|API Publishing, Sharing, and Discovery||Done on an Enterprise Developer Infrastructure/Network that is accessible to all other applications within the Enterprise.||Done on an External API Portal that is accessible to External Partners and third-party developers.|
|Purpose of API Consumption||Increase internal app development productivity, integrate applications within and across LoB resulting in streaming business operations.||Increase partner business opportunities, create new business models, and in some cases, direct consumer integration.|
|API Discovery||Need to be discovered on the same developer platform used by other internal applications willing to consume the APIs.||Need a public-facing portal to discover the APIs, explore them, and sample them.|
|API Subscription||May not need a stringent subscription plan to consume the APIs.||Need diverse subscription PLANs for API consumers to subscribe to and then consume based on SLAs, Payment Plans, etc.|
|API Policing||Need to make sure access of APIs are metered, rate-limited, and accessible based on Enterprise LoB needs and access rights.||Need fine-grained API control around security, access, rate limits, SLAs, and access limits based on Partner usage models and subscription PLANs.|
|API Access||May or may not need special tokens or keys to access the APIs. Mainly depends on the sensitive nature of data being exposed.||Need API Keys and security tokens to access the APIs.|
|API Invocations||API Invocations are in very large numbers as they are consumed by the Internal Applications.||Dependent on business requirements for access to external stakeholders. May be a much smaller number for Enterprise LoB Use Cases.|
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. At WaveMaker, we aim to make the journey from internal to external API Publishing a seamless one. As mentioned in my earlier post, WaveMaker Studio, via API Designer feature, allows for publishing, sharing, and consuming APIs internal to the enterprise. As these APIs become foolproof, and enterprises like to develop an ecosystem around it, they can use WaveMaker Gateway that allows for publishing, sharing, management, and consumption of APIs by external partners and third-party developers. WaveMaker Gateway provides full-fledged API management capabilities and is specifically designed, positioned, and priced for enterprises wanting to embrace and develop API Ecosystems around Partners and third-party developers. Click here for a demo of WaveMaker Gateway.