Internal APIs are designed primarily to streamline software development and simplify systems and operational processes. These currently represent the vast majority of use cases.
Internal APIs are often overlooked since they are aimed at in-house developers. These types of APIs generally work with proprietary data specific to a company and its departments. Although this data must be protected, it must also be accessible to those who work with it. Internal APIs allow for exactly this kind of secure access, creating more efficient development cycles for their products.
Similarly, a private API allows for some parts of a company’s data and applications to be accessed by developers working within that same company. These APIs may be used to create publically accessible applications, but the API itself is usable only by the company’s own developers.
Private APIs allow developers to work efficiently by providing a centralized pool of internal software resources. Developers can use these resources to build multiple, varied applications and products which are later accessed by the public. This streamlines development and reduces resource load, allowing the company to provide more services and products to customers.
Benefits of Internal APIs
One core underlying principle is that API development must be business-value focused. Internal APIs should add value through factors such as cost savings, speedier time to market, and increased quality of products and services.
- Internal APIs enable developers to build new, relevant apps quickly and securely. The API is a layer of abstraction that connects disparate parts of the business. This layer allows for quick adaptation to changing requirements, bringing flexibility to the development process.
- APIs allow for inter-departmental interactions that draw on shared resources. These APIs secure data while keeping it accessible. This is achieved by decoupling the consumption of data from the underlying systems of data accessed by the API.
- Inter-departmental APIs can be tailored to work with the specific needs of relevant departments, leading to more efficient interactions. Consistently-designed RESTful APIs provide a powerful way to achieve this efficiency.
- As organizations grow and become more complex, API ecosystems allow for efficient development across multiple applications and channels. This results in a streamlined service that delivers information in real-time.
- Internal APIs allow for the automation of existing tasks through simple APIs instead of heavyweight custom code. Without the need for specialized connectors or proprietary integrations, this backend automation is a streamlined way to save time and money.
- Taking advantage of RESTful internal APIs will allow your organization to automate and expand its services at a fraction of the cost, and without compromising data security or functionality.
Do I Need an API?
APIs enable digital strategies and digital transformation by unlocking the power of your information assets. But developers be warned — embarking on an API program does have its pitfalls.
- API Strategy: An API initiative should not be initiated without first understanding what is in it for the business; what is the business problem being solved, and what does the business benefit? Does it give you a faster time to market? Does it help your reach new customers or markets? Does it reduce costs or drive efficiencies? It’s important to understand that APIs are the means to reaching the goal. Unless these goals are well understood and what success actually means for the business, the chances are that an API initiative will fail to meet expectations.
- Product Knowledge: API products are intangible/digital goods that satisfy the needs of application developers who seek quick access to information, functionality, and innovation that is necessary in order to deliver your expected product. You may have the best APIs on this planet but if you don’t treat it as a product and don’t connect with the prospect (internal or not) then you can’t drive the value from it.
- The Importance of API Teams: The most successful API initiatives focus on building APIs that make it easy for developers to access content and data from internal systems, with the right levels of security and access control with ease of use. And for this you need a dedicated API team who will complete the core of building API — getting it set up and published. Many organizations realize the importance of breaking the data silos to share information across departments in a more seamless way. And having the right team in place is the secret to success.
The Amazon Moment
One day in 2002, Jeff Bezos issued a company-wide mandate that transformed the then bookseller to a $1B Infrastructure as a Service (IaaS) API, cloud computing leader. The memo was as such;
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
- It doesn’t matter what technology they use.
- All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
This API manifesto is often seen as the cornerstone of Amazon’s success. APIs were built as a consequence of the memo. And those APIs served as the foundation for Amazon Web Services (AWS), Fulfillment By Amazon (FBA), and Amazon Alexa.
How to Build Like Bezos
Enterprise or not, language and framework aside, the best approach is to develop your internal API as you are preparing to externalize it. Not only will you build a usable product for technical employees to connect, discover, and reuse IT assets, but you will enable self-service channels for accessing data that’s required to do anything from reporting and analytics, to building new apps, to creating and modifying processes — all without breaking IT along the way.
API Development — Consider your choices
There are several ways to create an API. Which one you pick will depend on the skills you have available to you, the feature set you need to support, time and budget.
Here are some broad guidelines:
1. Code it using your favourite programming language
Skills required: Back-end or full-stack developer.
Time: Build: medium to long. Deploy: long until you automate it.
Cost: Build: time and material for the developer.
Hosting: depends on where you want to host it. You will need to do this yourself.
Other comments: Use your favourite framework to do the heavy lifting
- .Net: ASP.NET | Open-source web framework for .NET
- Java: Spring
- Python: Django
- Ruby: Rails
- PHP: Laravel
2. Code and configure it on your favourite IaaS platform
Skills required: Coding, understanding how APIs work, knowledge of the services offered by the IaaS platform and how they interact.
Time: Build: medium to long. Deploy: fast.
Cost: Build: time and material for the developer.
Hosting: depends on IaaS platform, usually pay for use.
Other comments: The basic building blocks of this type of solution are serverless functions like AWS Lambda or Azure Functions running behind their API management services. You might experience some limitations, especially when requiring integration with systems or data not running on the platform. A good explanation of this kind of architecture can be found at Serverless Architectures.
3. “Code” and configure it on your favourite low-code platform
In theory, low-code tools should allow for faster development of systems using skills that are more readily available at the cost of the tooling and the risk of the project failing due to tooling constraints.
Skills required: Have coded before or have a clear understanding of coding concepts.
Time: Build: fast. Deploy: fast.
Cost: Low-code platform. Build: time and material for developer.
Hosting: Often included but depends on platform.
Other comments: Low-code tools like Outsystems or Linx are good choices when time is of the essence or you do not have access to a back-end or full-stack development team.
While low-code seems to be a no-brainer barring the cost of the tool itself there are too many variables and risks to consider to just decide that low-code is the answer. Each project will need its own business case based on the
- Type and complexity of the system to be built.
- Skills available and cost of those skills.
- Suitable low-code tools available and cost of the tools.
- Value of time-saving vs. the risk of project failure due to tooling.
The sweet spot is when you have domain experts with coding skills, even if they’re not pro developers, using a tool compatible with the target domain.