 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
APIs have long been the backbone of modern software systems, architectures, and businesses. They now dominate the web, accounting for 71% of all internet traffic. Generative AI is accelerating this trend, especially as we pivot our interaction with common web-based capabilities, like “search,” in favor of AI-enriched variants. More AI leads to more APIs, and with that, APIs act as an important mechanism to move data into and out of AI applications, AI agents, and large language models (LLMs).
Perhaps most interestingly, AI itself is set to become the biggest API consumer as agentic workflows perform automated API-heavy interactions on our behalf. Are we equipped to cater to a self-serving machine consumer? And as we race toward this new dawn of AI-augmented solutions, will the challenges faced (some still to be solved) over the last decade of sprawling API-enabled digital solutions become too much to bear, detrimentally impacting quality and, ultimately, our success?
Over the last decade or so, a methodology used to improve the overall approach to API delivery has been API-First. This simple approach focuses on seeing and treating the capabilities offered as an API (or API set) first and foremost. These APIs then form the building blocks for value generation.
The approach encourages thinking about APIs as the fundamental element being delivered in digital form and ultimately about that interface together with the problem space being solved. Thinking about the interface contract aims to promote better interoperability, consistency, and reuse that is not bound by the current state of the technical landscape.
To go deeper, consider some of the principles of API-First.
As companies have navigated their way toward digital transformation, recognizable business, organizational, and technical drivers have indicated the potential for tangible returns on investments for adopting API-first approaches. Many drivers reappear as companies strive to make headway and participate in the AI-fueled market.
Organizational Drivers
Organizational and Technical Drivers
Naturally, not all drivers apply to every organization, but knowing what to look for can be a helpful reference point as strategies are being operationalized.
Establishing metrics and measuring the expected outcomes is equally important as investments are being made in adopting API-first approaches.
Some tactile areas can gauge the before-and-after picture as forays into API-first practices are operationalized.
Business Benefits
Organizational and Technical Benefits
Implementing an API-first approach at scale is a nontrivial exercise. The fundamental reason for this is that API-first involves “people.” It’s central to the methodology that APIs are embraced as socio-technical assets, and therefore, it requires a change in how “people,” both technical and non-technical, work and collaborate.
There are some common objections to adopting API-First within organizations that raise their head, as well as some newer framings, given the eagerness of many to participate in the AI-hyped landscape. Here’s a non-exhaustive list:
Isn’t API-First just Big Design Up Front (BDUF)?
The simple answer is it’s not! Like any form of agile software delivery, we should strive to understand the minimal viable product we can ship, which is valuable for its consumers. For APIs, it’s no different. Don’t try to design for all eventualities. Instead, follow good extensibility patterns that enable future evolution and design “just enough” of the API based on current needs. There are added benefits when you combine this tactic with API specifications (like OpenAPI, AsyncAPI, or Arazzo), as you can get fast feedback loops on that design before any investments are made in writing code or creating test suites.
Our teams are staffed and equipped to write and release code – now we’re forcing them to deal with additional formats like YAML, JSON, OpenAPI, etc. Is this not just slowing us down?
API-First advocates for us to really consider the shape of the API from the consumer’s perspective. Working quickly toward an artifact like an OpenAPI description allows you to validate many concerns upfront from the consumer’s perspective.
There’s a whole ecosystem of tools out there that are compatible with a host of specifications across the various styles of APIs. Interoperability means teams need not be overly concerned with the additional cognitive load of dealing with additional formats. If you like working with YAML, there’s a tool for you, and equally, if you prefer to operate with a low-code visual editor or even a more natural language-orientated approach, there are tools for that, too.
This richness of the ecosystem around API specifications is important on multiple levels. First, it ensures architectural resilience as organizations are not locked into a single tool or vendor. Second, the variety of experiences dramatically lowers the barrier to participation across different stakeholder groups, further strengthening the argument that these APIs are socio-technical assets. Third, (arguably most importantly) these formats are how we present our APIs to consumers (both human and machine). Therefore, more focus should be put on their qualitative properties!
Our UI is our product, and specific AI models can consume UIs directly, so why would we shift focus?
Of course, user interfaces are essential, and entry points are even differentiated to value for many companies. Think of all the SaaS companies worldwide where UIs play an important role. UIs are, however, transient by their very nature. They evolve with trends and human experience expectations. Does the UI mean just the web or browser-facing interface? Or does it also include native mobile application user interfaces? Even in the world of SaaS, there can be many other channels through which consumers interact with the capabilities on offers like command line interfaces (CLIs), continuous integration pipelines, or system integrations directly through APIs, meaning that the UI is just one of the multiple touchpoints that any consumer might have with a SaaS provider. Are we thinking holistically about the overarching customer experience (CX)?
In many other industries, proprietary user interface usage is declining. Companies are instead looking to participate in larger B2B or B2C ecosystems by directly integrating into such ecosystems. Embedded Finance is an example of this, where the market is expected to grow above $7.2 trillion by 2030.
The recent Claude announcement of AI computer use is a great innovative example of how we can leverage our investments in user interfaces to let AI augment our human workflows, freeing humans to expend more of their grey matter on higher-valued activities. There’s a case to be made here, especially in legacy interfaces, that can uncover short-term value rather than expending the effort of creating nice, new APIs.
Good APIs are cheaper to build and have more consumer options than good UIs, and therefore, API-First is here to help prepare companies for the inevitable shift to APIs being far more useful for AI agents than UIs.
Convenience technology has a habit of biting back, and while there can be short-term gains, there is also a risk that executives misinterpret those gains as cheaper, faster, and a more consistent way to enable AI goals. Just like with Robotic Process Automation (RPA), it could be a costly and brittle hot fix if not paired with a parallel architectural shift toward API maturity.
It’s valuable data, not the transport pipe; we invested heavily in capturing and managing data. API-First is not essential to us as we can provide access to data.
Many companies have invested heavily in data warehouses, lakes, and factories. Many are sitting on terabytes or even petabytes of data. However, data in its raw form, or even when lightly transformed in a data factory, can only be helpful with the crucial ingredient of context. Providing direct access to data repositories may seem efficient. Still, it often offloads the burden of interpretation and integration onto the consumer, leading to confusion, misinterpretation, and ultimately error-prone outcomes. Beware of the sunk cost fallacy in this regard.
An API-First approach is powerful precisely because it starts with a use-case-oriented mindset, thinking about the problem being solved and how best to present data that aligns with that solution. By exposing data thoughtfully through APIs, companies can encapsulate domain-specific knowledge, apply business logic, and ensure that data is served securely, self-service, and tailored to business needs. This approach shifts the responsibility of contextualizing data from the consumer to the domain experts, reducing cognitive load and ensuring data is delivered in a more consumable, reliable format.
Beyond making data more accessible and meaningful, APIs enforce boundaries, protecting sensitive information and preventing unintended exposure of internal taxonomies or messy data structures. Data becomes a curated product within domain boundaries, supporting a governed, consistent, and scalable approach to integration. This becomes even more crucial when making your data available to LLMs.
In an AI-driven world, API-First is not just about connecting to data; it’s about delivering value and insights that are secure, domain-aligned, and built to serve specific purposes, enhancing productivity and accuracy in the process.
While the AI hype cycle may fluctuate, the fundamentals of high-quality APIs remain constant — what benefits human consumers will also benefit the new wave of machine consumers. As AI agents and automated workflows increasingly rely on APIs, we must ensure our interfaces are optimized for human developers and AI models.
Emerging standards from groups like the OpenAPI Initiative, including the Arazzo Specification and Overlay Specification, enable richer semantics and determinism in API interactions, bringing contextual depth and adaptability into API-driven workflows.
To prepare for this shift, here are some strategies to ensure your APIs are robust enough to support AI-driven applications:
These strategies collectively create a resilient, AI-ready API infrastructure. By preparing your APIs with these principles in mind, you’re ready for today’s human and machine consumers and well-positioned to adapt to whatever the future holds in an AI-augmented landscape.
This article is part of The New Stack’s contributor network. Have insights on the latest challenges and innovations affecting developers? We’d love to hear from you. Become a contributor and share your expertise by filling out this form or emailing Matt Burns at mattburns@thenewstack.io.
