In our cloud era, the increase in mobile and the need of 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 (read aboutThe Rise of REST API). 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.
Internal Private APIs
One of the key considerations that should guide both your API business strategy and your interface architecture is the distinction between open and private APIs. An interface is defined as open or private depending on whether it targets external or in-house developers. In this lesson, we explain the distinction in detail and explore ways it may impact your API program.
Not as much attention is paid to APIs that are internally facing. That is not so surprising, considering their purpose. But just because internal APIs don’t get as much notice, does not mean they are any less important to an enterprise.
Companies have a lot of data that is proprietary and can’t be shared outside its doors. Whether it is employee social security numbers or the “secret sauce” that sets their product apart from competitors, there is always some information that needs to be protected. Just because it is protected, however, doesn’t mean that it can’t be made more accessible to those that should have access to it.
A number of companies have internal API programs that help them become more efficient in aspects such as product development, HR and customer service. Both The Guardian and USA TODAY have internal API programs that have helped them speed up their app development process. The Guardian has found that its internal API traffic is about 6-7 times that of its external traffic. Evernote states that its ratio of internal to external API traffic is 99:1.
A private API is an interface that opens parts of an organization’s backend data and application functionality for use by developers working within (or contractors working for) that organization. The new applications these devs create may be distributed publicly but the interface itself is unavailable to anyone not working directly for the API publisher.
Private APIs can significantly reduce the development time and resources needed to integrate internal IT systems, build new systems that maximize productivity and create customer-facing apps that extend market reach and add value to existing offerings. Rather than creating siloed applications from scratch, devs can draw from a common pool of internal software assets.
External Open APIs
An open APIs is an interface that has been designed to be easily accessible by the wider population of the web and mobile developers. This means an open API may be used both by developers inside the organization that published the API or by any developers outside that organization who wish to register for access to the interface.
An open API publisher is usually seeking to leverage the ever-growing community of free-agent app developers. This will allow the organization to stimulate the development of innovative apps that add value to its core business, without investing directly in development efforts – it simultaneously increases the production of new ideas and decreases dev costs.
An open API may be used by internal developers but it is fair to say – in most cases – the success of an open API program will depend on its ability to attract external developers and help them create truly valuable new apps that people actually want to use. Open API publishers need to engage developers and they need to make sure these developers are successful.
Internal API Management
API management is the ability to document, publish, share, control, consume and monitor 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:
- Providing easy means to manage the lifecycle of APIs (Create, Design, Develop, 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 real-time access and usage trends of APIs and take actions as required by the business.
Benefits of internal APIs
There’s a considerable list of reasons why internal API programs are beneficial, not the least of which is their ability to help an enterprise learn the ways of APIs within the comfort and safety of the corporate perimeter.
Here are some more:
Enabling lines of business
There are organizations within a company that has no developers—that is, no technology people to build an app. But departments like marketing often have the mandate to respond to new customer expectations, are faced with slow-moving IT, and have the budget to hire developers to build apps. Exposing a business’ data and services via APIs enables those developers.
Cross-department security and streamlining
A common concern for enterprises, even internally, is keeping data and services secure when providing access to a company’s backend. Cross-departmental interactions are easily secured and streamlined by APIs.
Building an app-enabled business
As companies become larger and more complex, many are deferring to API ecosystems to minimize the amount of development effort to support multi-channel enablement. Dell is an exemplary in using internal APIs to better support internal development teams, partners, and retailers. The company provides Dell Mobile applications for both Android and iOS devices that make use of product catalog, product advisor, and CRM APIs to efficiently deliver critical business information in real time.
Systems of record have vices and virtues. The most important virtue: they generate revenue. If you are in the hotel business, then your system of record is your reservation system; if in finance, it’s your stock trading system; in the automobile business, it is your inventory and analytics system that predicts economic cycles.
Because enterprise systems are stable, they are often slow-moving and do not allow for core systems to keep up with market evolution. By thinking as a platform–that is, putting APIs between the database and the apps–enterprises achieve agility and flexibility while taking advantage of the stability of those systems.
Let’s take a look at differences in the requirements when it comes to publishing and consuming APIs,
Let’s see the differences between internal and external API’s:
|Internal APIs||External 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 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 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.
Internal APIs for business agility and flexibility
Often, demand for an internal API is driven by the need for mobile applications or portals to handle internal business processes, including HR or CRM functions.
Keeping things secure and while providing access—a core strength of APIs—is often important even within an organization. Cross-departmental projects today often require big program management apparatus and onerous processes.
Legacy IT systems tend to be stable, but also slow moving, and so can’t easily keep up with market evolution. By putting APIs between IT systems and apps, agility and flexibility result, while still enabling a business to take advantage of the underlying stable systems.
Tackling an inward-facing project enables the API team to learn important lessons—by starting with a smaller project, but also by gaining access to data on usage metrics—while keeping the project scope small. The API thus starts to add value immediately while setting the groundwork for later-stage developments.
It is also very important to have an eye on the whole REST API development process , it will speed up the development and increase you time to market.
Every company has a lot of data. The key is to figure out which audience is appropriate for each data set, and then open up that data to the correct audience via APIs. If an enterprise does that, it will see great returns for its brand image, customer satisfaction & retention and internal efficiency.