What’s the point of an API? Ask most developers that question and they’ll tell you that APIs are useful because they connect different applications or services together.

But the importance of APIs extends even further. By embracing a concept known as API-driven development, you can leverage APIs not just as a tool for helping to build applications, but also as the very foundation of your entire development strategy.

This article explains what API-driven development means, why it’s important, how you can implement it and how to overcome common challenges associated with API-driven development.

Put simply, API-driven development is the practice of designing and building APIs first, then creating the rest of an application around them. In this way, API-driven development is different from traditional development strategies. Those usually include API design and implementation as one point on the development timeline, but that does not make it the first step in application production.

The terms API-driven development and API-first development (another way of saying the same thing), have been in use since about 2010, but it is only within the past couple of years that they’ve entered into popular usage as more and more software delivery teams have recognized the benefits API-driven development provides.

If you take a traditional approach to APIs and design them after you’ve laid the groundwork for the rest of your application, it can be easy to overlook or ignore some components when deciding which parts of the application to serve via APIs. For example, when it comes time to build the APIs, you might realize that one of your application services formats data in a way that makes it difficult to fit into your API, and as a result, you decide that redesigning that component in order to make it accessible via an API is not worth the effort. You thus end up with gaps in API accessibility.

In contrast, when you embrace APIs as the foundation for your entire software architecture and delivery strategy, you put yourself in a position where it’s hard to forget to make an application component compatible with and accessible via an API. As long as you adhere to an API-driven development model, you’re unlikely to encounter negative surprises that limit API compatibility within your application.

API-driven development also naturally encourages application architectures that are highly distributed and modular. When you start by building an API framework that can connect together disparate parts of an application, you make it easy to break the application itself into modules, and to deploy those modules across a distributed environment that the API connects together.

A full discussion of the benefits of a modular and distributed architecture is beyond the scope of this article, but most developers and sysadmins today would agree that this approach maximizes application flexibility and scalability.

It’s not only the architecture of your application itself that is more modular and flexible under an API-driven development approach. The same benefits apply if you use a Continuous Integration/Continuous Delivery (CI/CD) to deliver the application using DevOps methodologies.

When you use APIs to break your application into distinct modules, you can continuously deliver each module separately. As long as each part of the application — and, by extension, its place on the CI/CD pipeline — remains compatible with the API interface and architecture that you defined, a problem with one module (such as a bug that crops up during testing) is unlikely to cause a delay in the rest of the pipeline. Each module can be updated separately, and at a different pace, while still remaining compatible with other modules thanks to the API that they share in common.

One obvious but critical benefit of API-driven development is that it helps to avoid incompatibilities between your API and your application. As noted above, if you wait until your application is already designed and built to start creating its APIs, it’s easy to run into unexpected situations that make parts of the application hard to reconcile with an API. But when you start with the API, the chances of that happening are much lower.

Another benefit of API-driven development that is likely obvious to most developers is that it leads to applications that are inherently cloud-friendly, because they are built first and foremost for connectivity.

On this point, it’s important to keep in mind that there are two different types of APIs — those that connect an application’s internal services, and those that connect the application to other services in the cloud. Having one type of API doesn’t necessarily mean you have the other. But when you embrace API-driven development, even if it starts with building internal APIs, you help ensure that you think from the start about all of the APIs that your application needs.

That is likely to lead to an application that integrates easily with external applications and resources in the cloud.

One of the chief challenges that many IT organizations face today is the fact that software delivery requires several different teams — developers, IT Ops sysadmins, software testers and more. If you aren’t careful, you’ll end up with each team operating in its own silo, which is inefficient.

But how do you actually do this in practice? Part of the answer is to embrace API-driven development, which provides a central point of reference for all of your teams to work with. In other words, when APIs are the cornerstone of your application architecture and delivery process, then everyone — from developers to production-environment sys admins and everyone in between — can focus on building, testing and monitoring APIs as a way of keeping the entire delivery pipeline flowing smoothly.

This approach helps to smooth over the communication and visibility problems that can occur when you ask your different teams to focus on code itself, which different teams will interpret in different ways.

Last but not least, API-driven development is a useful strategy for avoiding obsolescence of both your application and your APIs.

Today, it’s easy for an application to become obsolete because either it’s APIs become too difficult to modernize, or the application itself is difficult to integrate with modern API frameworks.

API-driven development is not a total guarantee that these things won’t happen. If you fail to keep your APIs up-to-date, your application can still become obsolete. But by keeping APIs at the front and center of your focus, API-driven development helps to forestall this eventuality.

Now that we’ve discussed the benefits of API-driven development, let’s take a look at how you can go about implementing an API-driven development approach to software delivery.

In an ideal world, you’d be building a new software delivery pipeline from scratch, and making APIs the cornerstone from the start. In the real world, however, it’s likely that you already have a delivery process and application architecture in place and you need to migrate to an API-driven development model. The latter scenario is more difficult, but by no means impossible.

Here are the steps that you can follow to transition to API-driven development.

Step 1 – Identify which APIs you currently use
Step one is determining which APIs you currently use — or at least have implemented, even if you don’t actively use them in your current deployments. This includes APIs for both internal communication and for integration with external resources. This step may seem overly basic, but it’s essential for ensuring that you don’t miss any APIs that you don’t often use.

Step 2 – Identify new APIs that you should implement
Next, you should determine which APIs you do not currently have available but that you would like to implement. You should evaluate how much effort you will need to invest to implement the new APIs, but don’t leave new APIs off your list just because they will be difficult to build. Instead, create a long-term plan that will allow you to implement all of your new APIs over time.

Some APIs may require you to rewrite or refactor substantial amounts of your application codebase, and you may not be able to make the switch to API-driven development overnight. But even if the journey takes time, it will yield valuable results in the long run.

Step 3 – Assess API architectures
You should also take time to assess which API architectures you want to use for your application, like SOAP, REST, gRPC, and so on. You may currently use one architecture but wish to switch to another. Or maybe you have multiple types of APIs in place and you want to consolidate them (which is usually — though not always — a good idea).

Step 4 – Move API design to the front of the CI/CD pipeline
Once you know which APIs you are going to create and how you’ll architect them, it’s time to place API design and implementation at the start of your CI/CD pipeline. In other words, before your developers even write new application code, your entire team should be deciding what APIs will be used to access the application components of which that code is a part, and where the new code fits within your overall API architecture and strategy.

Once you’ve done this, you’re effectively doing API-driven development.

Step 5 – Continuously test and monitor your APIs
In addition to starting your delivery pipeline with APIs, you also want to make sure that other critical stages of the pipeline (software testing and monitoring) also address APIs. Write tests to ensure that API functionality is vetted before applications are deployed, and add API monitoring tools to your software monitoring routine so that you can detect API problems in production environments.

Step 6 – Establish a continuous feedback loop for APIs
The final major step in implementing API-driven development is to build a feedback loop into your CI/CD process that ensures that downstream information about APIs (which you can glean from pre-deployment API testing and post-deployment API monitoring) is fed back to your API designers and developers. This way, feedback related to APIs can be used to make continuous improvements to your overall API architecture and strategy.

Challenges of API-driven development
Like any worthwhile innovation, API-driven development presents some challenges. The most common include:

Technical skill sets. API-driven development requires everyone on your team to have an understanding of APIs and how they work. This doesn’t mean that everyone has to be an API expert, but it does mean that people who don’t traditionally know much about APIs (such as software testers) will need to gain new technical skills.
API consistency and compatibility. The more APIs you build, the harder it becomes to keep them consistent and compatible — especially when you are delivering multiple applications and want to ensure API consistency across all of them. This is a challenge you can overcome, but it requires a high degree of communication and visibility across your team.
API security. While the flexibility and scalability benefits of APIs are well worth the extra security burden in most cases, the fact remains that applications that rely centrally on APIs can be attacked via those APIs. Monoliths without APIs don’t have this additional attack vector. Addressing this challenge requires building API security best practices and tests into your CI/CD pipeline.
API management burdens. Managing and monitoring large numbers of APIs at scale is a daunting task, especially when you rely on a largely manual process for keeping track of API performance and responding to API problems. This is one reason why automated API management tools are helpful for enabling a practical API-driven development strategy.

API-driven development remains a relatively new idea. But as the world of software delivery becomes more and more cloud-centric, API-driven development will be important for giving organizations a leg up and ensuring maximum connectivity and flexibility for the software they deliver.

Embracing API-driven development certainly takes some work, and getting there won’t happen overnight in most cases (especially if you are starting with an existing codebase that was not designed for maximum API compatibility,) but through careful planning, and with the assistance of API management tools, every organization can get there.