I have been wanting to chat with Daniel Kocot for a while now, and finally found an opportunity to have him by for a conversation on API specifications. He has a very nuanced view of OpenAPI as well as TypeSpec through his work on the ground within European enterprises. He shared his honest views of OpenAPI, but also helped educate me more about TypeSpec which is being championed as a...
I had my old partner in crime, Adam DuVander over for an API Evangelist Conversation. We immediately went back to the old ProgrammableWeb days and lamented that the blog and API directory is gone. We talked a little about why the site went away, and what it says about the wider API storytelling space. It feels like it was a little bit about the companies who had acquired the site ove...
With his latest post API Complexity Is a Lie, How some businesses live off API complexity while others sell simplicity, Bruno Pedro nails a reality that perpetually weighs on me daily as part of my work. It is easy to be excited by the latest API hype cycle when you live in the forest, but when you regularly head up to the rocky outcropping above the forest and sit thinking as I have for almost 15 years, it becomes m...
It is the top question I get–where do I go to learn about APIs? I’ve long had a list of the blogs, directories, podcasts, and other resources for learning about APIs–the trick is to keep it up to date and always properly reflect what is truly happening. I’ve reworked my previous work on this subject while at Postman as a YAML powered blog post that I will dynamically update on a regular basis.
I was joined by Sebastian Loch, Business Development at FatSecret for a conversation about how they have managed their nutrition data API since 2007. I connected with Sebastian as part of my profiling their API for APis.io, and after we talked a bit, he caught my attention by mentioning how much work goes into not just operating a highly curated global database of nutrition data when every AI out ther...
I came across a post on LinkedIn from Alex Akimov, the CTO of Monite, sharing their strategy for versioning their API. I knew that I wanted to get Stanislav Zmiev, the Tech Lead of Platform Engineering at Monite, and the person behind their API versioning on the show. Versioning is an important and hot topic, and Stanislav delivered with a very wise, pr...
I sat down and had a conversation with Pat Patterson, Chief Technical Evangelist at Backblaze. It was the first edition of my new podcast with someone other than me. ;-) Pat is an industry veteran, and someone I have followed the lead of for well over a decade. He makes for a reliable first guest because he can talk on just about any subject, but he has deep experience as an evangelist, s...
I have been mulling over everything I found included in the five API governance job posts I came across the previous week. As I said, there was a lot being asked across those job posts, and the way qualifications, responsibilities, and skills were used was bothering me–they are very jumbled. The other thing that really bothered me was how all of the job postings focused on it being this single persons job to do everything as opposed to them being the definer, facilitator, coordinator, and...
Getting teams producing APIs to care about APIs is an equally daunting task of getting business leadership to care about and invest in APIs. This post overlaps heavily with my thoughts on what actually matters to API leadership, as these apply to leadership as well, but is primarily focused on the middle and lower levels of the enterprise. I would love for everyone to care about doing APIs well, but in my experience, the people who truly care about APIs will always be less than 5% of the p...
Getting enterprise leadership to care about APIs is the top challenge in the API universe. Everybody benefits with executive leadership mandates the prioritization of APIs, and invests in all stages of the API lifecycle. While I have spent an enormous amount of brain power on this subject over the years, I feel like it has primarily been from a vendor perspective, which always has the goal of convincing leadership to buy, not necessarily care or understand. I am looking to develop an ongoi...
Change is the great enemy of a successful API. There are many ways that change can erode the quality, performance, velocity, and trust with the APIs we have powering desktop, web, mobile, and artificial intelligence applications. The versioning of APIs is just the tip of this iceberg, and there are other properties of our API operations that can positively or negatively impact API operations as APIs change, the operations around them change, consumers using an API change, or the industries...
I have cared about API specs over code for some time now. I have long invested in OpenAPI for defining the surface area of HTTP APIs, APIs.json for defining the surface area of API operations, JSON Schema for validating it all, and Spectral rules for governing it all across the API lifecycle. However, in the last five years I’ve developed stronger opinions about the role that infrastructure, tooling, and services play as part of helping or hurting API governance efforts. Like programming l...
There is a lot of talk today about platforms. A topic that has evolved over the years, beginning with waves of startup technology platforms, and now followed by everyone thinking they are a platform. There is a lot of focus within enterprise organizations right now to centralize a platform, with a significant portion of that work focused on what many consider the API platform. While my definition of an API platform might not exactly match the definition popularized in this moment, there is...
People don’t read documentation. People don’t have time to read books. But, I find people pretty receptive to absorbing API guidance in bite-size snackable chunks. My last book The API-First Transformation that I wrote while at Postman had the seeds of what I mean by guidance, but I define all my guidance as simple Jekyll powered YAML artifacts that help me modularize and reuse API guidance across my stories. The one thing that didn’t make it into the API-First Transformation book was the ...
JSON Schema is the most important API specification today. I’ll fight anyone on this. It is more important than OpenAPI, AsyncAPI, GraphQL, Protocol Buffers, and even my own APIs.json. Why? Because every aspect of API operations is defined and validated by JSON Schema. OpenAPI and AsyncAPI both use JSON Schema. Every enterprise organization is using JSON Schema, most just are completely unaware they are, and aren’t very good at applying it evenly. JSON Schema is how API operations are defi...
Adopting 3rd-party infrastructure, tooling, and services is an inevitable reality of API operations today. You will depend on 3rd-party infrastructure and services like GitHub, Postman, or Jira, and having a strategy for the history of why you have relationships with these vendors, and how you are using as part of your API operations, is a critical step towards getting a handle on the API sprawl and chaos that exists, wrestle with your legacy technical debt. Having a clear API vendor strat...
I’ve been researching, talking to people, and writing stories about API governance for a while. I’ve been working with OpenAPI for many years, and have been immersed in the creation of governance rules with Spectral for over five years now. I left the insulated world of a startup to spend a year in a medium-sized enterprise to learn more about what API governance was, and what it isn’t. Now I am looking to take these learnings and offer what I know as a service to other enterprises, while ...
Enterprises are interesting entities. I am very keen on understanding more about the how and why they operate, but I am also very keen at avoiding getting ground down by the churn of enterprise gears. I enjoy mapping the business, technology, and people landscape that exists across enterprises in different industries. I enjoy hearing stories about what matters to business and engineering stakeholders across different enterprises. I enjoy crafting strategy, programs, platforms, policies, li...
Augmenting a specs-only approach to API governance, I am continuing to invest in a GitOps-Driven API source of truth. I don’t care if it is GitHub, GitLab, or BitBucket, but Git is the core of your API governance, and the factory floor of your API operations. These three pieces of infrastructure I give a pass to when it comes to my specs-only policy. I also require that business and technical stakeholders both equally be able to engage around APIs.json, OpenAPI, JSON Schema, Spectral rules...
The gateway for moving towards an API contract focus with API Evangelist was the discovery of APIs and trying to figure out how to make APIs more visible to business stakeholders. API discovery is the one area of the API economy I consider myself an expert, as I’ve been studying since about 2012, and have been working to evolve my APIs.json discovery specification since 2014. While looking for solutions to the API discovery problem,
There are fewer topics I’ve discussed more than the concept of the API lifecycle. I’ve worked for years to try and standardize how I tell stories about the API lifecycle, and have worked with number API service providers when it comes to standardizing their offerings to help define each stage of the enterprise API lifecycle. The API lifecycle will mean different things depending on who you talk to in the enterprise, which is one of the reasons you must nail down a common working definition...
I have been working to understand REST, WebHooks, GraphQL, WebSockets, MQTT, Kafka, and gRPC side by side as protocols and patterns, but also as the specification that define them like OpenAPI, AsyncAPI, Protocol Buffers, and Postman Collections for about six years solid now, with another five years previous studying what it meant to have a diverse API toolbox. I agree that enterprise organizations will need a multi-protocol approach to API governance, but I am making the executive decisio...
The lack of business and technical alignment across API operations was the number one concern I heard across my 125+ guests doing my Breaking Changes podcast. In my experience, the lack of alignment between what the business side of the enterprise wants, and what the engineering side of the enterprise wants, is the number one cause of friction, chaos, and sprawl across API operations. What product managers, and sales are asking engineering for when it comes to what consumers need increasin...
The next phase of API Evangelist will be defined by API contracts. The phrase API contracts has been thrown around loosely over the years to describe an OpenAPI definition, and used as part of a specific type of API testing where consumers are involved called API contract testing. I am co-opting and elevating the phrase API contracts as part of the next stage of evolution of API Evangelist, but also the API economy, using it as a vehicle to help govern the enterprise. Per my definition, an...
I have been looking to develop analogies for APIs that will make more sense to business folks. I’ve settled in on using what people already understand, the supply chain. But, instead of the raw physical materials and labor that goes into physical products, I am talking about the digital raw resources your business depends on available in your internal data, content, and algorithms, as well as those acquired from 3rd-party producers. My intent with this analogy is to bring more visibility t...
