Internal vs External 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.

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.

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.