Some consumer‑facing APIs are so widespread they’ve become household names – think Google Maps and Stripe – but internal APIs are the real powerhouse of the API economy.
Internal APIs – by which we mean APIs exposed only to clients and developers within an organization – are a key pillar for an enterprise’s digital transformation efforts. Building internal APIs is usually the first step in the development of digital products and services. In fact, according to IDC’s recent survey, APIs – The Determining Agents Between Success or Failure of Digital Business, supporting internal integration of applications and products is one of the top priorities for API development initiatives in enterprises.
Why are internal APIs important? What are the benefits of internal APIs? And crucially, what’s the most optimal architecture to manage them? This blog addresses these questions to help you deliver internal APIs securely and at scale.
Internal APIs unlock data silos and build bridges by opening an organization’s disparate backend systems for use by other developers within a line of business (LOB). For example, a manufacturer’s marketing organization may need visibility into systems used by the supply chain organization to determine whether to discount certain products and models to target the right market segment and maximize revenues.
How do internal APIs break down silos? They provide a common interface that supports data interchange using standard formats such as HTML or JSON. It’s easy and quick not just to build an API but to consume one as well. Contrast this with the use of proprietary database connectors and arcane data interchange protocols to retrieve information from data repositories. By reducing friction, APIs significantly improve productivity. These APIs are not exposed to external developers and third parties. Internal API traffic is within the organization – hence within the corporate firewall.
Internal APIs accelerate time to market and reduce the time and cost of software development. Let’s go through the benefits in detail.
Internal APIs provide an easily consumable layer of abstraction for connecting various parts of a business and provide the flexibility to adapt to changing requirements. Rather than create a siloed tech stack for each LOB’s applications, developers across the organization can draw from a common pool of internal APIs to access data. This eliminates duplication and reduces software development time, thereby improving developer and IT productivity.
Internal APIs promote the development of a system of record that serves as the authoritative source of key data elements in an organization. To ensure data integrity, there must be one – and only one – system of record for a given piece of information. If each LOB has its own data or even a slightly different version, it leads to discrepancies and confusion. Internal APIs are an efficient mechanism for accessing this single source of truth.
Efficiency results in cost savings – there’s no need to build proprietary platforms with heavy customizations within each LOB. There‘s also no need to build or buy expensive connectors and integrations that are essentially point tools.
As an example, the federal government of Estonia operates X‑Road, a data‑exchange platform that connects all government agencies in a seamless fashion. Estonian citizens don’t even need to carry their driver’s licenses, as that information can be quickly retrieved from the population registry and vehicle registry – even though the two data repositories are separate. This report from the World Bank conservatively estimated that by making it easier to access information X‑Road had saved the Estonian government and citizens 2.8 million person‑hours in a single year (2014).
Let’s go through some best practices for managing internal APIs.
To efficiently define, publish, secure, and monitor and analyze both internal and external facing APIs, you need an API management solution. A developer portal that allows internal developers to quickly learn about published APIs is also needed.
Microservices is a new architectural approach to software development that is gaining traction. Many enterprises are either rearchitecting their existing internal applications or building new ones using this framework. In microservices architectures, APIs are the means of communication both between clients and the microservices‑based application and among the microservices that make up the application. When an API client requests resources from a backend application, an API gateway routes the traffic to the appropriate microservice. The API gateway also authenticates calls and applies rate limits to prevent attacks that might occur if external actors manage to breach the corporate firewall.
Microservices are “chattier” than monolithic applications, with high volumes of “east‑west” traffic among microservices. So it is very important to choose a high‑performance gateway that can process at high throughput (requests per second) and deliver responses very quickly. Client requests often spawn multiple API calls to different microservices, so a delay at the API gateway for even one call can potentially have a cascading effect and result in very high latencies.
Although there are first‑generation cloud‑based solutions that provide full lifecycle API management, they are not suitable for handling internal APIs. Because their architectures tightly couple the data plane (the API gateway processing API traffic) and the control plane (which performs API management functions), at runtime every internal API call must be routed through the API management solution’s cloud. This has two disadvantages:
For security reasons, internal API traffic must remain behind the corporate firewall, which precludes routing calls to an external cloud. This is true even for enterprises that host applications and APIs in their own private cloud environments.
There several ways NGINX helps you manage your internal APIs.
The NGINX API management solution’s innovative architecture is designed for scale. NGINX supports distributed API management by decoupling the API gateway (NGINX Plus) from the API management software (NGINX Controller [now F5 NGINX Management Suite] ). There is no runtime dependency between the two, which ensures that API traffic is processed without unnecessary overhead such as additional scripting, database calls, or other control plane logic.
The decoupled architecture gives you maximum flexibility in where you deploy Controller [NGINX Management Suite] and the NGINX Plus API gateways – you can deploy them on premises, in the public cloud, or even across multiple public clouds if your corporate network extends to the cloud. Internal API calls do not need to be routed through a cloud outside the corporate network, as the NGINX Plus API gateways that handle API traffic can be deployed independently behind the corporate firewall.
Do you have internal APIs? Or are you planning to develop internal APIs? Are you routing your internal APIs through the cloud? We’d love to hear from you in the comments below. In the meantime, get started with a free 30-day trial of NGINX Controller [NGINX Management Suite] today or contact us to discuss your use cases.
"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."