To help me understand where I am going I wanted to take a quick walk through how I got here, and spend some time geo locating myself as I enter into some conversations this week about what is next for 2025. My goal is to share a distilled down version of everything I’ve absorbed from doing APIs over the last fifteen years and help explain my location in the API universe at this moment. I enjoy a very high level view of the API space which spans almost every industry, and are behind every major technology advancement this century, however, explaining this reality to your average business person is a challenge I am determined to overcome in the coming years.
Understanding how I got here is key to understanding where I am going. It has been an educational fifteen years, and while APIs seems to be a priority for business leadership, I am looking to roll my experience up into a series of productions I can use to target business folks with over the course of the next fifteen+ years. While I have aspirations to sell services to the enterprise, and I might have the appetite for another startup selling a product to the enterprise, I also have a much loftier set of goals to keep influencing the API industry with my storytelling and help standardize and regulate what is happening across the top industries where APIs are having significant impact.
HTTP APIs
I was able to reach new heights in 2008 running registration for SAP SAPPHIRE in Orlando and Google I/O in San Francisco using AWS APIs for my team’s compute and storage infrastructure, as well as bringing new and interesting experiences via HTTP APIs powering mobile applications. By 2010 I found myself wanting to better understand how simpler HTTP APIs were transforming the landscape of web and mobile applications, resulting in me starting API Evangelist to better understand the technology, but also the business implications of using HTTP APIs to power web and mobile applications.
API History
In 2010 I began researching the approach of first phase API pioneers like Salesforce, eBay, and Amazon, while also becoming a student of second wave pioneers like Flickr, Facebook, and Twitter, but landing on a firm belief that third wave pioneers like Twilio and Stripe had the formula we should all be following. It was an exciting time to be at the intersection of cloud, social, mobile, and APIs, and is a time period that has informed a lot of the stories that we tell across the space like the Bezos API mandate, and Obama’s mandate that all federal government agencies should go machine readable by default.
API Management
The conversation from 2010 through 2015 was carefully crafted and shaped by early waves of API management providers who were selling gateways that were bundled with API portals, documentation, and the ability to monetize access to public APIs. This narrative about making your enterprise digital resources publicly available to generate direct and indirect value for your business became a powerful message. It is a message that still permeates the discussion today despite the majority of API growth being internally, and externally powering 1st-party and partner applications.
API Discovery
As the number of APIs kept growing I found myself writing for ProgrammableWeb, and heading to Washington D.C. to catalog public JSON and XML datasets for the Obama Administration. Coming out of my Presidential Innovation Fellowship I started the APIs.json standard, and APIs.io search engine to apply what I had learned in the public sector, but applied to APIs in the private and public sectors. Since then I have helped launch and grow the Postman API Network, and have renewed my work on APIs.json and APis.io to continue working on defining what a successful API search engine can look like today.
API Specifications
Throughout this journey I have been regularly reminded of the importance of adopting API specifications like OpenAPI, JSON Schema, and Postman Collections. These artifacts are how you define APIs, as well as API operations, allowing teams who are producing and consuming APIs to get on the same page. Spectral rules have emerged as a common format for defining rules that help assess the quality of an API, wider API operations, as well as entire industries of APIs. While many see API specifications as just a configuration for docs, SDKs, gateway, and other experiences, I know they are central to everything.
API Consumers
While working on API management and discovery, and evaluating the impact API specifications were having on the sector I found myself developing a deeper understanding of the relationship between API producers and their consumers. I spent numerous years surveying and assessing the API landscape from the perspective of an API consumer, culminating in 4 years at Postman, the leading API client for API consumers. Most API narratives, services, and tooling focuses on API producers, but there is much untapped power that exists within the API consumer community, which is something that Postman was able to take advantage of.
API Experience
As full lifecycle API management became commoditized it began to break apart into more modular services, tooling, and narratives that spoke to specific experiences that both API producers and consumers faced throughout API operations. Documentation, mocking, software development kits (SDKs), monitoring, testing, security, and other critical areas of API operations were getting more attention in API discussion. With new services and tooling emerging to deliver new experiences that were often defined and automated using open-source API specifications that were standardizing the API experience.
API Products
Over the years, APIs have continued to impact more of our business operations, a need to begin treating APIs more like a product emerged. Business stakeholders being to get more involved in the planning and delivery of APIs, and service providers were beginning to court API product managers with new dashboards, and other services or tools that would speak to what business stakeholders needed. As the number of partner and public APIs grew, the more API product managers were getting involved across the API lifecycle, engaging with the consumers of APIs throughout the API lifecycle to better shape future versions of an API.
API Governance
With the rapid expansion in the number of internal, 1st-party, but also 3rd-party APIs the need to standardize and govern APIs has grown significantly over the last five years. Open-source rules linting engine Spectral has emerged as the leader in governing the consistency of HTTP APIs using OpenAPI, and now AsyncAPI, and OpenAPI workflows using the Arazzo specification. A wave of API governance service providers have emerged to help apply spectral in standardizing the surface areas of APIs, but I’ve uncovered that there is just a huge need to also lint wider API operations and provide the guidance teams need to deliver consistent APIs at scale.
API Surveying
Along the way I’ve learned that API discovery is both an essential and often unseen and uninvested aspect of API operations. API discovery was baked into API management, but then became distributed and federated as API experience evolved using API specifications. I’ve learned that the politics of APIs often gathers with services purchased to manage API operations, but that real value accumulates on API specifications as they make their way throughout the API lifecycle. This experience has left me with a deep understanding of the role that API specifications, discovery, and governance plays when it comes to the entire API landscape.
API Storytelling
JSON and YAML wrapped in markdown stories via Git has been the life blood of the API economy for me. I have spent fifteen years researching and having conversations with API producers, consumers, analysts, and service providers, producing many good, many not so good, and a handful of great stories that speak to the intersection of technology, business, and politics APIs. My stories, guidance, and the conversations and questions I have gathered throughout fifteen years has shown me just how central storytelling is to the technology and business of this, but also how these stories can shape policies that will matter to the people who are being impacted by APIs in their everyday life.
It is really hard to distill fifteen years of my API journey down into less than 1000 words. I’ve learned a lot over the years and have made a lot of mistakes. I’ve worked with companies, organizations, institutions, and government agencies on their API strategies. I’ve worked with multiple well-funded API startups, and have shifted my view of the API landscape to help me reach the vantage point I possess at this moment. The question for me now, is how do I take all of the building blocks of this journey and make it available in the most meaningful way via API Evangelist to sustain my work and help enterprises make their way forward within all of this API sprawl.
