At the AFCEA Alamao ACE Event in November of 2023, a lofty goal was stated to those in attendance. The United States Air Force, through Chief Technology Officer Jay Bonci, announced the modernization and standardization of APIs across the United States Air Force (USAF) through the adoption of API-first solutions.

This commitment is significant as it could inspire more API-first development within government departments at large. Let’s dive into this concept today. We’ll look at what API-first is, what the USAF plans for its adoption, and what implications this process may have for the security posture underpinning the USAF.

What is API-First?

API-first is a software design philosophy that prioritizes the development of application programming interfaces (APIs) at the beginning of a project. By setting the API as the core development measure and guideline, APIs are treated as first-class citizens as opposed to technical byproducts.

In an API-first approach, the API is designed before the actual product or service. This means the API is not an afterthought or an addition to an existing product but the core component around which everything else is built. In such an approach, how users interact with your interface, how well it is documented, and how efficient it is in practical use are all considered health markers for the API itself, leading to improved design and developer experience.

An API-first strategy usually requires collaboration between the potential users of the API and the internal development teams. This collaboration means feedback is introduced into the process early on, helping align the API to the user needs and improving outcomes. Beyond improvements to the user experience, this can also dramatically decrease the time to market. Since the API is developed first, frontend and backend teams can work in parallel, leading to faster development and quicker time to market with a product that better fits the use case at hand.

An API-first approach brings indirect benefits like reusability, portability, and better consistency across different parts of their application. Having a well-designed API from the start benefits the long-term, too — it’s easier to adapt to new technologies and platforms in the future while ensuring continual user alignment. API-first can serve as a stable contract between different parts of a system, even as the implementation details change.

The US Air Force Goes API-First

Now that we have a firm grasp of the API-first model, let’s look at a real-world example: the United States Air Force.

Any military organization lives and dies by one thing: logistics. Logistics have formed the backbone of every major component in the armed forces since time immemorial, and it is this basic concept that underpins much of the US Air Force’s efforts to improve their API holdings.

USAF has labored toward the goal of connecting every sensor and system to unify joint force operations across the globe. This is a huge goal that brings with it significant complications. Beyond the fact that every sensor and system might carry a different internal platform or solution, there is also the very real fact that these systems are dispersed across a world with varying modes of communication, qualities of interconnected networks, and general availability of resources.

To achieve this goal, the USAF has begun to focus on the standardization of their APIs through the use of API-first design. Jay Bonci, the Department of the Air Force Chief Technology Officer, shared this goal at the AFCEA Alamo ACE Event in November of 2023, stating:

“APIs enable real-time, authoritative data sharing for coalition joint all-domain command and control (CJADC2) that ensures mission success on a global stage.”

The USAF intends to achieve its goal by adopting API-first design. The biggest value that the team sees in this approach is the highly collaborative nature of the principle. As Bonci noted:

“We will be able to start to get public feedback, and that public feedback is for everybody in this community [across industry and the service] but also the [joint] community. We want to make sure that we’re aligned with DoD and aligned with our allies and partners.”

The USAF is beginning its efforts by standardizing API formats, systems, and services, with a particular focus on unified procedures and credentialing. By centralizing the API process underpinning the logistics systems of the USAF, Bonci sees a solution to the problem of differentiated data systems and scalability, especially in relation to data warehousing freshness and the ability to share this data between organizations and units.

“We have invested heavily in data platforms, and they very well serve our analysts and science community. The platforms have built a huge amount of benefit for us. But that data is stale. We pipe that data in and it could be six hours, 12 hours or a month old. And when you’re comparing data with different staleness, your results get less authoritative. But it’s still a great model. It is still great for analysis that you don’t need to do in real time. […] Any sufficiently large tech organization has had to solve this challenge and they have had to develop these services. Your Microsofts, Amazon, Google, Teslas. It is a new area for us. We have to stretch to make our systems talk to each other to get to that JADC2.”

The USAF currently has a wide range of APIs across various paradigms, including REST and WebSocket solutions. The primary issue they currently have is that the interconnection between these systems is weak and non-standardized, which impacts the ability to share the data at scale and to ensure that the processes underpinning them are scalable to new domains. Because the API was not developed first, the experience is typically poor, even if each individual API does what it’s technically supposed to do.

Notably, Bonci considers this to be as much a technical problem as a social one:

“We do have a lot of technical details to nail out. But we’re going to outline these types of principles in our reference architecture so that we can receive feedback from the community, both on the business relationship side for how system owners want to be able to control their data for what makes sense in a regulatory construct. And then what makes sense for your developers in technical ways. In the next few months, we are going to be putting out more and more topics on these areas. It’s key for our data foundations. It’s key for our software factories. It’s key for the larger DAF software community, including our vendor partners. And it’s going to be key for what our story is going to be for JADC2.”

This is universally true of API-first adoption for organizations who may not be familiar with the approach. API-first eschews many development paradigms of previous decades, and as such, it can often be a change to the minds and hearts of developers as much as the projects they work on.

Zero-Trust and Regulated Environments

Highly regulated environments, like the USAF, have major considerations to make around the concept of zero trust. Zero-trust architecture is a security concept centered on the belief that organizations should not automatically trust anything inside or outside its perimeters and instead must verify anything and everything trying to connect to its systems before granting access.

Traditionally, security models assumed that everything inside the organization’s network could be trusted if it derives from a system known and validated as “safe.” The reality is that some of the most damaging attacks can come from systems internal to the network or service, and as such, everything should be circumspect. Zero-trust operates under the principle that trust should never be assumed, regardless of where the request originates or what resource it accesses.

Zero-trust requires strict identity verification for every system, person, and device trying to access resources, regardless of whether they are sitting within or outside of the network perimeter. These systems typically also operate using multi-factor authentication, which requires more than one piece of evidence to authenticate a user. This might include something the user knows (a password), something the user has (a smartphone), or something the user is (biometrics). Zero-trust also requires limiting user access through a least-privilege approach and securing data and processes by granting access only when such access is necessary for a specific function.

This approach requires consistent validation and monitoring. The security posture is not just a one-time verification — it requires continuous checks to ensure that the posture is complete and productive.

Because the USAF operates across services and systems that govern some of the most secure functions in the United States, the underlying systems must operate within a zero-trust architecture. Whereas other systems may be exposed by hackers or criminals occasionally, the USAF is literally in the midst of a cyberwar at any given moment. As such, organizations like this should consider their API a prime target for operants inside and outside the system itself.

Conclusion

The movement within the USAF to adopt API-first is a sensible one. The Air Force benefits from having a centralized command infrastructure that allows for the guidance of global development in a way that other organizations do not, and in this case, adopting API-first as a centralized development paradigm can lead to a more secure, extensible, and user-friendly experience.

What do you think of the USAF adopting this approach? Alternatively, is there a situation in which API-first may not be the best approach? Let us know in the comments below!