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.

The OpenAPI Community

22 Nov 2021

I am taking a moment to recalibrate my chess board for the OpenAPI community, and there is no better way for me to accomplish this than to write a story here on the blog. I have several folks I am working with to help move the OAS conversation forward as part of official OAI efforts, but also as part of Postman Open Technologies, and having a map of the landscape loaded up into my head and easily referenced as part of conversations helps me move things forward. As of November 22nd, 2021, here are all the moving parts of the OpenAPI discussion for me, organized as a simple narrative focused on moving the community forward: Learning I do not want to assume everyone knows what OpenAPI is, and here are the links you should tune into if you are looking to learn more about this important API specification: Website - The OpenAPI website. Documentation - The OpenAPI documentation. Getting Started - Where to get started. Blog - The OpenAPI blog. Twitter - The OpenAPI Twitter account. These are the basics of where you can learn about what OpenAPI is, and how you can put it to work, then stay in tune with the community via stories on the blog and conversations on Twitter. Contribute If you are wanting to do more than just learn what is happening I recommend using these resources to quickly understand what is happening and get more involved at the technical level. Specification - The repo for managing the spec. Github Issues - The issues driving the spec road map. Discussions - The Github discussions for the spec. You can find everything you need to keep up speed on what is happening with the spec from a technical point of view using these links, and contribute to the conversation and overall road map. Meetings There are two core meeting that you can tune into to get a handle on the technical...[Read More]

Design-First, Prototype-First, or Code-First APIs

20 Nov 2021

I strongly believe in a design-first approach to delivering new APIs, and future iterations of existing APIs. Having an OpenAPI artifact to guide discussions, services, and tooling saves you time, money, and frustration across the API lifecycle. This isn’t opinion, this is fact. However, I also have grown to be very pragmatic in how I approach the API lifecycle, and fully grasp that adopting API-first effectively across teams isn’t something that all enterprise organizations will have the time, skills, and other resources to make happen. Resulting in me supporting design-first, prototype-first, and code-first approaches to delivering APIs. I will keep investing in stories and demonstrations of what, why, and how API design-first makes sense because these three realities I see across the landscape keep me from getting too dogmatic on this subject. Design-First - Using an OpenAPI to document, mock, test, and iterate upon a new or existing API make sense if you have the time and skills, but when you don’t it is something that can become half-baked and causing problems throughout the API lifecycle, so make sure you are properly investing in API-first, and not just jumping on the bandwagon. Prototype-First - This one actually surprised me, but when I saw folks prototyping APIs using a Postman collection, which provides the ability to mock and document your API without an OpenAPI, but then generate an OpenAPI once you get to an agreed upon state, I began making sure prototype is part of the equation when it comes to delivering APIs. Code-First - Coding is what most developers get, and there are plenty of ways to use annotations and proxies to still ensure there is an OpenAPI for code-first projects. Using code-first approaches to rapidly prototyping while still adopting many of the iterative approaches to moving an API forward can be just as effective as many design-first approaches. It would be nice if everyone could just stop what they are doing and learn OpenAPI...[Read More]

Being Transparent By Default and Over Communicating When Doing API Specifications

20 Nov 2021

I forget what a great vehicle API Evangelist for sub-tweeting conversations that I see occurring across the API universe. I made a career out of doing this for the last decade, taking a moment to anonymize and generalize conversations and realities I witness across the space, writing up here as a story, and using them to help educate and bring awareness to the API universe. One that I am finding myself doing more storytelling about is about the transparency and communication necessary when building API specifications. I wrote about this last week on the Postman blog showcasing the radical transparency of the AsyncAPI community, and it is something I want to continue highlighting because it is very difficult to get and keep people’s attention in this digital world. You have to be transparent and open by default when you are building API specifications. I don’t say this just for some hand wavy ethical stance, but it is critical to ensure your community is informed and aware, and keep people from gumming up the works with their lack of understanding and obstruction to forward motion. While doing the hard work of moving any open source specification or tool forward you find yourself inundated with drive-by feedback from folks, and if you aren't extremely clear about how folks should be tuning into the conversation, and make every action public across multiple channels, this feedback will be even more uninformed than it has to be. People just don’t have time in their busy days, and most people aren’t equipped to see the work that is already occurring within an open source community. So when they do come across a single issue, meeting, or other relevant conversation, the likelihood that their feedback will be uninformed and not in alignment with the community is pretty high. People, especially men excel at stepping into a conversation wildly unprepared, uninformed, and oblivious to the hard work volunteers and the community are already...[Read More]

Needing Inspiration to Care About APIs?

18 Nov 2021

I always enjoy when I have the opportunity to light up someones imagination when it comes to APIs. I have had a couple of conversations with folks recently who had never heard about APIs until they talked with me, and then after fifteen minutes of chatting had developed a curiosity around the fascinating acronym. I have been captivated by APIs for almost twenty years, with a decade long obsession around everything API. APIs keep my attention because they come in so many shapes and sizes and are something that is touching almost every aspect of our personal and professional worlds. I have to admit though, there are times where I get sick of APIs, but inevitably I come across some new use of APIs that renews my passion and interest. I get the reality that not everyone cares ab out APIs at the level I do, but I am always happy to try and convince people that they should care, even if they aren’t a developer. One way I am able to capture people’s attention when it comes to APIs is by having a treasure chest of stories about how APIs can make a difference in areas that people care about. One recent area of inspiration I stumbled into involves a story I was reading about Fighting food wise, one apple at a time in the Washington Post, which is summarizes as follows: Katherine Sizov is only two years out of college, but her high-tech sensors — which monitor ethylene, a gas key to the ripening of fruits and vegetables — are keeping watch over 15 percent of U.S. apples. Which after reading I typed “Strella Biotechnology”, the name of her company plus “API” into Google. This is something I do multiple times a day as I am reading an interesting article. It is how I perpetually stumble into interesting areas of API development and meet people doing interesting things with APIs. Strella Biotechnology doesn’t...[Read More]

Open Tech Partnership with APIMATIC

15 Nov 2021

We have some great partnerships occurring within the Postman ecosystem. You can tune into storytelling from our developer relations around how we are partnering with Salesforce, Stripe, and other leading API providers. When it comes to API Providers who offer up services that can be used across the API lifecycle, I am taking the lead from the AsyncAPI team, and making everything open by default. We are the Postman Open Technologies (OT) team after all, and there is no reason that the work that goes into these partnerships should be locked up, which is something that provides me with an ongoing storytelling opportunity beyond just the storytelling we do about partners, but also the process behind these partnerships. Partnerships with Postman Open Technologies begin as a Github repository where we do all the planning, but then quickly move to public workspaces where we can demonstrate the value of each partnership. To show our partnership process in action you can learn about how we are partnering with the APIMATIC team around their code generation, portal, documentation, and transformation capabilities. The partnership has a dedicated repository with a README, but then we are kicking things off with a handful of tasks we are tracking with issues. In the world of Postman partnerships, everything begins with a team profile and a public workspace to demonstrate the value of the partnership. Team Profile - Publishing a formal APIMATIC team profile with info and links to their platform. Team Workspace - Lighting up a public workspace that has their OpenAPI and reference collection. It is common for partners to just put an OpenAPI, and a reference collection that provides a list of all available API resources into their workspace, but then we’d like to move forward with what we consider to be ecosystem integration collections that power the API lifecycle, with two key ones planned for APIMATIC. API Definition Transformation Ecosystem Integration - Create a collection that makes it simple...[Read More]

A Blueprint for Hands-On API Storytelling

15 Nov 2021

I am spending a lot of time studying and profiling how my teams at Postman do what they do. Last week I wrote a piece on how AsyncAPI is moving forward their specification out in the open, and this week I wanted to showcase how Joyce Lin (@PetuniaGray) the Director of Developer Relations (Devrel) at Postman works her magic. Joyce is very prolific in her storytelling at Postman>a, and is well-known for her Better Practices pieces, live streams, videos that include her dog Lucy, and much more. However, one of her recent pieces of work I think is worth singling out and highlighting because it is cool, but also to help me flesh out a formal blueprint out of her approach, providing me with something I can share with the rest of the Postman community. Joyce’s recent work, production, game, puzzle...I am not sure what to call it—is called Lost in Space. She calls it a puzzle hunt, but I am looking to generalize it beyond just a puzzle or game, and showcase it as a blueprint for an API-first storytelling production. Joyce provides the story behind Lost in Space, and gives it this description: In this game, six members of the International Space Station (ISS) have been knocked out of orbit by a solar flare. Together, they must piece together the clues and figure out how to get back on course and return home. The puzzle is super creative, complete with a video and compelling narrative that pulls you in, but it also makes it all very hands-on and interactive using a Postman public workspace, and of course it is powered by APIs. Joyce’s video introduction for Lost in Space is so over the top creative and just pulls you into the game, bringing the story of the puzzle to life. Like Joyce, I am not a big puzzle player, but I fully get their attraction, and find the creativity that went into this...[Read More]

Some Thoughts on API Governance

13 Nov 2021

API governance is a massive subject that takes regular work to make sense of and to be able to successfully articulate to others. With the growing number of APIs and microsservices in use across enterprise organizations, API governance is quickly becoming one of the most important areas of discussion for me. To help organize all of the moving parts of API governance into some (hopefully) more actionable guidance, I wanted to share some thoughts on API governance as I see it today. What is API Governance? API governance is ensuring that the complex systems powering the enterprise are as defined, discoverable, and observable as possible so that you can understand the state of the system, and then incrementally evolve the state of the system as a whole, in the right direction. Quantifying the system, but then allowing us to improve upon, standardize, and move the enterprise into a specific direction as defined by the business domains we operate within. Why Do You Need API Governance? Without API governance you will never achieve any level of consistency in the design, delivery, and operation of APIs across teams. Without a consistent approach to doing APIs, you will never fully understand or be able to influence the quality of APIs, and teams will always struggle to achieve desired levels of productivity in their work--something that will make the velocity of an organization perpetually uncontrollable and unpredictable. How do you do API governance? It takes a significant amount of planning, investment, and iteration to do API governance across a large enterprise organization. API governance involves defining all of your APIs as machine-readable artifacts, organizing, managing, and evolving them via a single API platform, tapping into the outputs of that platform to achieve the levels of observability needed to understand the state of the system. Then enabling teams to change behavior in how they design, develop, deploy, and manage APIs across a well-known API lifecycle, measuring, reporting, and communicating around...[Read More]

Using Postman Visualizer as a Data Editor

23 Oct 2021

I use and abuse the Postman platform for a lot of things it wasn’t designed for. In the same way that I have used and abused the Github platform for things it wasn’t designed for over the last five years. I find Postman collections to be infinitely useful for just about anything I want to do in the world of APIs, and recently I have been using them as little API-First data stores. Meaning I have little lists of things I want to curate and make available as simple APIs, and I find collections via the Postman platform to be a perfect way to manage lots of little datasets. I have a number of collections I use for data storage, but I figured I’d build my proof of concept data editor using Postman visualizer on my restaurant demo workspace. This is a workspace I use multiple times a week during meetings, demos, talks, and demonstrating how you do APIs in an API-first way, and I’d like to have a simple editor for editing the underlying data, but also available for demonstrating the power of Postman visualizer. My restaurant workspace began with an OpenAPI, but then I quickly generated a Postman collection, added examples, and published as a mock API—pretty standard API-first Postman platform stuff. I can plug the URL of my mock server into my collection and see the results each time I hit send for any of the paths I have defined. Each request in my collection has one example which is used for the API documentation and the mock server, and I am looking to visualize and edit the first request, which happens to be a list of my restaurants. Then using visualizer for the request I pull the JSON and render as a table, showing two the of properties for cuisine and menu, potentially allowing me to actually edit each property in my list of restaurants. Rendering the returning JSON as HTML,...[Read More]

API Management to API Gateway and Beyond

11 Oct 2021

It has been a while since I stepped back to assess the world of API management. API Evangelist was founded on the premise of studying and understanding API management, so it makes sense after a decade to spend a moment thinking deeply about the circus tent we have called API management. I will be working with my partner in crime in the Postman Open Technology (OT) group Kevin Swiber to really make sense of this subject over the next year, but to help guide our efforts I wanted to take a moment to recollect how the hell we got here. Kevin and I will be doing the hard work to make sense of where we are at with API management in this decade, and this blog post is just meant to be the old API guy rant on the front porch of what the hell just happened. The API Management Circus Tent In 2010, the API management conversation was dominated by three main players, Mashery, Apigee, and 3Scale, with a handful of service-oriented architecture (SOA) gateway players showing up trying to be the cool kids by 20212. API management was the only conversation and we really didn’t talk about much else in that moment, looking back it was very much a vendor-led discussion, something that you smell on the leather of the [Gartner API management limousine I am taking a ride in as a “visionary” today](https://blog.postman.com/postman-visionary-2021-gartner-magic-quadrant-full-lifecycle-api-management/). So, in 2012 (which I typed as 2021 just now), what was API management? Portal - That single destination where you go to find all of your APIs and consumers are able to onboard, see documentation, and find what they need. Documentation - Accurate and up-to-date documentation for all your APIs, helping reduce friction for API consumers when putting APIs to work. Onboarding - Providing the ability to sign up, log in, and manage your access and account as an API consumer using a standardized process. Plans - Being...[Read More]

Starting Simple in the Overwhelming World of API Governance

08 Oct 2021

The world of API governance can be pretty overwhelming when it comes to trying to figure out where to get started. Almost everyone I talk to, beginner and expert, has a difficult time getting their head around what should happen first, so I figured I’d work on establishing some blueprints for getting started. When it comes to design governance there are a lot of rabbit holes you can fall down, but I find it helps focusing on some of the most common elements we can get mixed up when designing our APIs. Information The place to start with governance is to make sure we have the essential information for an API present, establishing the base of meta data that is needed to describe what an API does, being able to contact whoever is behind the API, and standardizing the licensing and terms of service being applied. Title - Every API should have a title that properly describes what it does. Title Max Length - The title of the API should be as concise as possible. Title Word Check - There are some words we do not want to see in the title. Summary - Every API should have a summary that describes what the API does. Summary Max Length - The summary of the API should not be too long. Summary Word Check - There are some words that shouldn’t be in summary. Description - Every API should have a detailed description of what it delivers. Description Max Length - We don’t want the description of the API to be a novel. Description Word Check - We want to filter out some words from the description. Contact - Every API should have a contact object present in the OpenAPI. Contact Name - There should be a contact person assigned to each API. Contact Email - There should be a contact emailed available for each API. Contact URL - The API should have a URL to...[Read More]