The volume of mobile applications with backend-as-a-service (mBaaS) resources for cloud connectivity is increasing every quarter. A few weeks back, a survey found that APIs are used in nearly 3 out of every 4 apps, to implement core features and functionality (web-based). In the last couple of years or so, the total volume of public APIs have almost doubled too, on a year-on-year basis. APIs can broadly be classified under two heads – Internal APIs and External APIs. We will here highlight the differences between the two, based on certain key parameters:

1. Nature of APIs

   In the context of enterprise APIs, the concept of ‘Line of Business’ (LoB) has to be understood first. An internal interface is one that is built to connect existing legacy systems with in-house applications, as well as to ensure smooth connectivity and interoperability of two or more internal applications. In essence, they are created, used and maintained by internal developers of an organization. On the other hand, an external or open API is created for third-party web/mobile app developers, partner entities, and other stakeholders. These are created by API providers as final products – and are often a significant source of revenue. Internal APIs work within the LoB of companies, while external APIs can be deployed both within as well as across the LoB.

Note: The clunky SOAP (Simple Object Access Protocol) methodology was initially used to create internal APIs. Since mid-2012 though, it has mostly given way to the much lighter and developer-friendly (HTTP-based) REST APIs.

2. Need

   The main purpose of internal APIs is seamless integration of the current IT system and setup within organizations, in order to boost productivity levels. They are, hence, created according to the business logic and objectives of the parent company. In addition to compressing the overall development cycles, these internal APIs help in adding value to a firm’s outputs (i.e., the APIs are a means to improve outputs, and are not final outputs themselves). The principle behind external API development is radically different. They are meant to be used by external coders to make apps – and hence, the precise requirements of these developers and API partners have to be carefully considered, while building external software interfaces. API companies design the interfaces as per the directives of the third-party developers. The latter are the API customers/end users.

3. User base

   External APIs (at least the ones that are successful) have a much larger user-volume than internal APIs. The former CAN be used by internal developers, but providers are typically more interested in pushing them out to external mobile app developers – with increased adoption figures translating to success. That, in turn, brings the importance of API marketing to the fore. API-makers have to identify and reach out to target user groups. In contrast, Internal APIs have a much more niche collection of users. They can be accessed and deployed only by the in-house developers of parent companies, to add functionality and value to existing setups. Anyone not related to the publisher of an internal API is not authorised to use them.

4. Ease of management

   There is a misplaced belief that internal APIs do not need to be managed by providers. While it is true that there is an additional layer of perimeter security for these APIs (since they are never used by any third-party element), even in-house developers often access them on unsecure mobile networks and public internet service providers. Unless the an internal API has a robust, updated security support, it can get exposed to threats and attacks. However, external APIs do need a higher degree of continuous API management, monitoring and governance – simply because they are used by a large contingent of external developers (whose behaviour can be unpredictable). In particular, making alterations in the interfaces can lead to application breakdowns, and resultant loss of clients. API management is important for both, with it being more critical for external APIs.

5. Discoverability

   API providers typically use customized, customer-facing portals to enhance the exposure and bolster the discoverability of external APIs. Web and mobile app development experts can browse through the interfaces on this platform, sample their features, and then select the ones they need. A new internal application program interface, however, has to be created on the SAME platform on which all the other existing apps (that need to access the API) of the organization exist. Otherwise, compatibility and usability issues are likely to arise.

Note: Large legacy systems might not be accessible on the mobile platform. Integrating internal APIs with such systems can be tough – particularly due to disparities in standards and protocols.

6. Motive of API providers

   We have already noted the separate groups of users for external and internal APIs. Let us now take a closer look at the purposes that an API provider wishes to serve with these two types of interfaces. Internal API tools are all about adding an extra edge to the regular business operations, and improving the in-house app development procedures. To be successful, an internal API must leverage the present IT setup in an organization in the best possible manner, for increasing productivity (through seamless integration of applications). External APIs, conversely, are built to suit third-party customers…to aid them in making custom cloud-connected apps and establish all-new business models. Certain external interfaces are directly integrable on consumer platforms as well. Over time, a open API can help in strengthening partner networks and consequent business opportunities too.

7. Type of API governance required

   Although both internal APIs and external APIs need strong management mechanisms, the type of governance necessary for the two differ (albeit slightly). While handling access limits and implementing rate limits (to avoid ‘overloading’ due to excessive network requests) are required for both internal and external interfaces, the latter also need deep-level service level agreements (SLAs) – depending on the degree and type of API-usage by external developers. The subscription plans opted for by API customers also have to be considered while creating the SLAs. On the other hand, internal APIs have to be metered and checked for reliability – as far as accessibility within the LoB (as required by internal developers) is concerned. The policing requirements for an internal interface are a lot lighter.

8. Attention of hackers

   Open APIs are available for use by software and mobile app developers worldwide. Developers, understandably, try their best to increase awareness about these APIs – and there is no way of excluding hackers and other shady users from these information. As a result, the risks of security breaches and hacks of external APIs are that much more – particularly if there are loopholes in their security. Internal APIs are, in comparison, much ‘safer’. Since there is a layer of confidentiality about their usage within organizations, hackers might simply be not aware of these software assets.

9. Publishing the APIs

   For an external application program interface to be of any use, it has to be readily accessible for third-party developers and authorised partners. To ensure this, providers typically publish these APIs on secure External API Portals (existing or built from scratch). At the other end of the spectrum, we have an Internal API, that has to be available to the other applications already being used in the IT setup of an organization. Hence, they are published on on custom Enterprise Developer Networks, that can be accessed by internal developers quickly, securely, and with ease.

Note: API sharing is yet another matter that has to be handled carefully for the two types of interfaces. External APIs must be easily shareable with third-party agents (customers), while internal APIs should be accessible to in-house stakeholders.

    10. Volume of network requests

With a much larger user-base, external APIs apparently should have a considerably bigger volume of invocations. However, that is not always the case – particularly in the early stages of the API lifecycle. The number of network requests faced by an external API is likely to be limited by its reach, and the precise purposes it would be deployed for by app developers. Open APIs that are used within the LoB of enterprises typically have a small user volume. Internal APIs, on the other hand, are likely to face a high frequency of invocations from the outset – since they are created for the very purpose of consumption by, and integration with, the already existing in-house applications.

     11. Need for subscription

An absolute must for external APIs, not so much for internal APIs. Mobile app developers need to check out the available subscription plans and SLAs (along with payment options) on APIs – to be able to make a choice that would best suit their requirements. Presence of multiple subscription offers makes these open interfaces flexible – a much-needed feature. Internal APIs, though, can do without subscription options. They are utilized by internal developers – and preferably, they should have a standard, uniform software resource to work with.

     12. Need for security tokens for access

Different internal APIs expose different elements of a company’s confidential backend information to developers working within the organization. Unless the data contained in a particular API is very sensitive, it might not be necessary to create a special security token to access it. Access control of external APIs (which are more vulnerable to security attacks) has to managed on a much more granular level. Professional API developers recommend the use of high-end security tokens and API keys – to maintain data integrity and minimize chances of unauthorized access.

Some externals make a distinction between strictly ‘internal APIs’ and ‘private APIs’. The former refers to interfaces that are created, owned and managed by in-house developers and are not distributed on the web. On the other hand, private APIs are those that are made accessible to close partner groups (on an ‘invitation-only’ basis).

In this external APIs vs internal APIs comparative study, we have focused on the main differences between the two types of software interfaces. Understanding these points is vital for effective, efficient and overall smarter API creation, management, maintenance and usage.