API Evangelist
API Evangelist is about making sense of the world of application programming interfaces, or simple APIs. APIs have become part of every layer of our Internet connected world over the last 20 years, and this is my research project into understanding what is happening. As of 2019 I am also the Chief Evangelist for Postman, but I still use this site in the same way I have since 2010, as a workbench for what I am working on each day. Providing me with a very public way to work through my projects, while helping others see the world of APIs in different ways, and hopefully learn more about how APIs are being applied across our world
This isn't meant to be a blog in the traditional sense of the word, and you should think of it as Kin Lane's personal notebook that he is fine with others reading. Once you spend time reading my work you will better understand that this is my souning board, helping me work through my ideas, and I am not doing this for page views, audience size, or other metric. However, after over ten years of doing this I tend to have a regular group of folks who are tuning in and providing commentary via Twitter, GitHub, and other channels.
A Postman Resource Bot
17 May 2022
A rite of passage for most new Postman employees is creating their first collection. I asked my new collection developer Bello Gbadebo (a href="https://twitter.com/gbahdeyboh">@gbahdeyboh), or “Debo”, to spend his first week on his first collection. Now that I am writing this, I realize the gravity of this situation, and very pleased that Debo rose to the occasion with a pretty kick ass first collection. Don’t get me wrong, I’ve seen some interesting first collections from new Postmanauts, but Debo really stepped up, hitting on all the right notes when it comes to demonstrating the power of a collection, with what he called his Resource Bot. Most Postman’s will build a collection that integrates with a single API, but Debo made one that scrapes, integrates with multiple APIs, and uses webhooks, and other advanced capabilities of a Postman collection. Here is the overview Debo provides for his Postman Resource Bot: “This collection is a slack bot that can randomly suggest resources and blog posts for you to read anytime you need it to. It has a set of commands that can be sent to it and what it suggests depends on the command it receives. To read more about its usage and commands, please read this article or watch this video.” The Resource Bot collection pulls entries from the Postman learning center, the Postman blog, and Youtube, but it its use of both Slack and Postman Webhooks to leverage the collection as a Slack bot that really elevates his approach. Also, the Youtube pull is pretty straightforward, but the learning center and blog are scraping. The collection is immediately useful and educational, demonstrates the power of APIs and scraping, while showcasing the automation power of a Postman collection with webhooks. It is an implementation that is spawning a bunch more ideas for collections for me, and different ways to help educate the community around the world of APIs, the API Lifecycle, and the Postman API Platform....[Read More]
API Perspectives
08 May 2022
I enjoy a privileged perspective of the world of APIs. It has been one that I have carefully crafted over a decade in the space. I experience and engage with a lot of perspectives, and I am always fascinated by how many perspectives there are in the API space, but also how many people occupy a single perspective and cannot see or empathize with those who enjoy other perspectives, or like me, multiple perspectives in any given moment. As I am doing other writing for work I wanted to take a moment and explore what the possible perspectives are that I regularly see in my API conversation, providing the baseline for the perspective I use in my storytelling, but also to help me in the moment while I am having conversations. API Producers - The version of the world that people who are producing APIs see, based upon what they want to achieve by doing APIs. Single API - A perspective that Is closest to the ground floor, thinking in terms of the resources and capabilities available in single API. Many APIs - Expanding and being responsible for many APIs, understanding what it takes to consistently operate and deliver many APIs. Type of API - Focused on a single type of API like REST, GraphQL, Event-Driven, and other patterns that are useful and possibly trendy. API Consumer - The view of the human being who is consuming an API and actually trying to put it to work as part of their business. API Producer / Consumer - How someone sees the world when they live simultaneously as both a producer and consumer of APIs. API Lifecycle - Looking at things from across the entire lifecycle, or from a specific stop along the API lifecycle, looking across all APIs. API Governance - Having a desire to govern API Operations, defining the guidelines, rules, and other constraints and enablement for APIs. API Roles - The technical writers,...[Read More]
Zombie API Portals
05 May 2022
I learned a new phrase a couple of months ago, and it is a phrase I have been hearing more and more amongst the conversations I am having on my Breaking Changes podcast, and with Postman customers as part of my regular engagements. The phrase is “Zombie API Portals”. Referring to an internal or external API portal that isn’t up to date and you really can’t tell if there is anyone home. We’ve all been at an API portal where nothing has time stamps, the documentation is static, and even when you ask a question or email them, you learn that indeed, there is nobody home. I really like the phrase Zombie Portal because as an API storyteller it is a phrase that captures your attention and evokes a shared pain we all face in a very pop culture way that also leaves you smiling. For me, this is API storytelling gold, and helps me do some heavy lifting to both get people’s attention, but also convey an important concept along the way. I have long joked about Mashery API portals always being a ghost town. Go check it out, almost every company who bought a Mashery API management solution back in the day is a ghost town, with the last blog post being 2011, and the last Tweet being around the same time. The "build it and they will come" vision for API providers didn’t always pencil out, and it didn’t help to be shelling out six figures on a 3-5 year contract with a major API management provider. However, this Zombie virus isn’t exclusive to Mashery, and is something you will see regularly across the API Landscape, where someone got a bee in their bonnet about doing an API, published a portal, documentation, and code libraries, then wrote a blog post and didn’t do much else after that. In the end, it is a lot of work to publish and API, but it...[Read More]
The Unbundling of API Management
05 May 2022
When you ask people involved in API operations what API management is you’ll get a whole mix of answers. API management as we are sold it emerged out of the SOA world around 2006. Over the years it picked up momentum until a number of acquisitions occurred and Apigee IPO’d in 2015, resulting in a bundling of various services API producers are in need of packaged as a single solution to what the enterprise needed. The bundling of API management capabilities was more about what API management vendors needed than it was ever about what API producers actually needed. Then around the same time API management providers were peaking, a new generation of API gateway providers were emerging to shift what the cornerstone of API management was all about, but also begin delivering the other bundled services as well. The core set of services enterprise organizations were purchasing from API management vendors over the years looked much like this: Gateway - Providing the front door, or if you will, the front gate for your API estate. Auth - Handling onboarding, authentication, authorization, and access to APIs. Policies - Plans, rate limits, scopes, rules, and other policies applied at runtime. Portals - The human landing page for all things API within enterprise or community. Docs - Help standardize and automate the publishing of API documentation and resources. Analytics - Providing a dashboard or reports showing usage, errors, and other data. Just as the old guard of API management providers were peaking, a next generation of API service providers were delivering features to unbundle what we know as API management: Gateway - Kong, Tyk, Hashicorp, KrakenD Auth - Auth0, Okta Policies - Who???? Portals - Postman, APIMATIC, Readme, Provonix Docs - Postman, APIMATIC, Readme, Redocly Analytics - Moesif, Resurface Labs Developers were needing almost all of the features API management providers were peddling, they just didn't need them all bundled together. You see, when you are a...[Read More]
The Myth of One API Service Provider to Do It All
05 May 2022
I hear enterprise organizations say that they need a single service provider to offer a bundle of services that meets all of their needs. I’d say this is the result of years of being told by analysts and API management providers that they were in need of a one size fits all tool. There is this strange dance that exists between enterprise leadership, analysts, and API service providers that evolve these narratives, leaving them as truths when it comes to infrastructure procurement. Sure, you have your bedrock solutions like source control, CI/CD, gateways, APM, and other infrastructure, but the myth that you can have one vendor provide you with everything you need to produce APIs just demonstrates your weakness in identifying yourself as an API consumer. You see, in order to find balance across the API lifecycle and API operations, you have to strike a balance across your existence as both an API producer and an API consumer. If your head is stuck in API producer mode you just one one solution to manage your APIs—give me everything I need in one bundle. If you are an API consumer, you want exactly the resource you desire, and you want it to be reliable and cost effective. You see the imbalance that exists if you only live as an API producer? You see this same illness with API management and other service providers, in that the ones who also have their own APIs will outlast the ones who do not. To make it in this business you have to be both API producer and consumer. You have to see the API lifecycle as something that is shared between both API producers and consumers, both inside the enterprise, and out on the open web. The belief that you should have one vendor to solve all of your problems is lazy from the perspective of the enterprise, and greedy from the perspective of the API service provider selling...[Read More]
OpenAPI is Your Source of Truth and Collections are Derivatives of That Truth Designed For Specific Business Outcomes
16 Apr 2022
I love the spectrum of API awareness that exists out there, and the challenge of trying to figure out how to move people "forward" across that spectrum. One of the most visible metrics of where an individual, team, or organization is at in their API journey is whether they say and use "Swagger" or "OpenAPI". While this is the most visible chasm that exists across this spectrum, there are many more dimensions out there based upon how you see and use OpenAPI, and how you see and use Postman collections. I don’t expect everyone to see things as I do, as I have been thinking full time about this for a very long time, but also I am biased because of my role at Postman. However, my view of the landscape is still relevant in helping provide milestone markers for others to at least consider as they make their way "foward" in their journey. There is a lot of confusion out there between Swagger and OpenAPI, but there is even more confusion out there between what OpenAPI and Swagger are for, and what Postman Collections are for. Both of these spectrums reflect where folks are in their journey, and the role that machine readable artifacts play in helping stabilize the lifecycle can be found across the varying perspectives of what Swagger, OpenAPI, and Postman Collections are used for. The most common constraint people apply is that Swagger and OpenAPI are just for documentation and that Postman Collections are for API testing. These views articulate where someone is at in their API journey, and how aware and standardized, or ad hoc and chaotic their view of the API lifecycle. OpenAPI is all about grounding the API lifecycle in a source of truth of what is possible with API, and the collection format specializes in deriving variations of that truth that speak to specific business outcomes. OpenAPI, formerly known as Swagger is a machine readable specification for...[Read More]
Twenty Problems That Postman is Solving for Developers in 2022
27 Jan 2022
A co-worker of mine Bob Fahey said a customer had asked what the twenty problems that Postman is solving for developers in 2022. I am in writing mode this afternoon so I figured I’d craft a post to try and articulate twenty of the common problems we were solving this year. I will most likely rewrite it for an official Postman blog post, but I wanted to cut my teeth on a meaningful list to share right away. API Evangelist is very much my playground for storytelling, allowing me to explore using my words to describe a variety of concepts, and then work on a more polished and coherent post for the official Postman blog when ready. Hopefully, this post can whet your appetite regarding what is possible when it comes to the problems that we are tackling at Postman when it comes to the development of APIs and the applications and integrations they power. Seeing Your APIs APIs are extraordinarily difficult to see. You might be able to see the response of an API using a client like Postman, but seeing the surface area of an API to know how to make a request can be very, very difficult, depending on the scope and complexity of the API. Postman gives you the controls to define and probe the surface area, understand the authentication, query parameters, path parameters, headers, and other technical details. Once you’ve successfully described the surface area of an API you can save that as a collection, which provides a visual interface for working with an API without having to write code. Collections allow you to “see” the surface area of your APIs, complete with documentation and visualization, but defined in a way that allows you to reuse, share, and work with as part of producing or consuming APIs. Finding Your APIs API work occurs across desktops and servers spread across the enterprise and the cloud. The average enterprise has thousands of...[Read More]
Stories > Code
23 Jan 2022
I have learned so much from my partner Audrey Watters over the twelve years I have been with her, but one of the most powerful concepts I have picked up from her and ran with in my own way is the importance of storytelling. Not just the importance of it, but really that it is the only thing that matters, and will almost always trump very logical ways of seeing the world that are ubiquitous in the tech sector. A good story will get you further than any perfectly written code or applications, and in a world drowning in technology, stories are not just how you stay afloat, or get ahead, but it is also how you stay sane in all of this. Over the years I have fused my approach to writing code with my approach to storytelling, producing quick and dirty solution solutions for each situation I find myself in. There are many examples of my approach visible on the web in any given week, but a “production” you will keep seeing throughout this year centers around OpenAPI listing rules in service of what is known as API design governance. One of our competitors in the API space created a very forward thinking approach to listing OpenAPI specifications called Spectral, which allows you to create little JSON or YAML rules that can be applied to “govern” the design of each API using an OpenAPI artifact. Spectral is leading the conversation when it comes to API design governance, but after much studying I found one area that I can both contribute to the open source solution, while also carving out my own slice of the API design governance conversation. Simply by focusing on the storytelling involved with each individual rule, rather than efficiencies involved with actually applying rules. As with most layers of technology, it can get pretty complicated and overwhelming to make sense of the potentially hundreds of API design governance rules you’ll...[Read More]
Knowing Where Each Version of Our OpenAPIs Are
23 Jan 2022
Almost every enterprise organization I know struggles with knowing where all of their APIs are. There are always shadow and invisible APIs that exist across the enterprise API landscape, and at with the pace of change that exists within the average enterprise today, this is something that will continue being a reality for most teams. Adding to the confusion across this reality, most enterprise organizations also do not know where each version of their APIs are, and while there may have been a significant amount of work done around defining OpenAPI or other artifacts for APIs, there rarely is consistent investment in linking together multiple versions of OpenAPI definitions. Resulting in OpenAPIs being spread across servers, Git repositories, and the desktop of developers, leaving us not knowing where each version of our OpenAPIs actually reside, rendering the unavailable for use in automating change management across our API operations. OpenAPI provide us with a machine readable way to articulate how change should be defined for each API, and the ability to automate across different versions of our APIs, but if we don’t always know where our APIs are, let alone the OpenAPI artifacts for them, and do not possess any way of articulating where each version of an API exists, we are left unable to govern and direct change across API operations. For example, if I want to detect breaking changes across a single API, I will have to have the context of where the last version of OpenAPI exists, knowing the branch, path, or specific location of each API artifact. To be able to effectively diff across multiple versions of your OpenAPI, you have to not just have common approach to versioning and storing your OpenAPIs, you have to have a common and machine readable way of articulating where they exist. OpenAPIs open up a whole other world of possibilities when it comes to discovery, governance, and managing our APIs, but the next frontier of...[Read More]
Detecting Breaking Changes Across API Versions
23 Jan 2022
API governance is still very much mired in the design phase of evolution, focused on the consistency in design of a single API. And while we all have a lot of work to onboard the enterprise masses when it comes to applying API design governance pragmatically, leading edge API service providers have begun shifting investment beyond just design, and focusing on more operational level concerns across many different APIs, or multiple versions of an API. You can see this present in the recent release of optic-ci from Optic, which allows you to detect breaking changes in the CI/CD pipeline using their open source approach to API governance that leans more in the direction of operations governance than design governance. optic-ci plugs into your Github pipeline using Github actions, Versions - Pulls the previous version o your API definition to compare alongside your current release. Diff - Conducts a semantic diff using both versions of your API definitions to understand what’s changed. Breaking - Looks specifically at what has changed and determines whether or not they are breaking. Pass / Fail - Passes or fails your pipeline run based upon whether or not there is a breaking change present. Source - Shows you the source of the breaking change, allowing you to know location within definition. This CI/CD pipeline solution for detecting breaking changes in APIs goes beyond the testing of each API contract, or even the surface area of the API releasing and considers what has occurred across two separate versions of your API. Taking into consideration not just the surface area of your API but also beginning to see your APIs as something that is changing, allowing teams to embrace change in a standardized way. It is difficult for teams to get a handle on what is happening across many different APIs, but it becomes exponentially more difficult for teams to get a handle on the different rates of change happening across many APIs....[Read More]
