The API Evangelist Blog

API Evangelist

Some API Specification Toolbox Projects That Will Make an Impact

12 Nov 2020

I have been conducting weekly discussions around API specifications each Friday mornings which I call the API Specification Toolbox. The goal is to just identify ways in which we can drive more discussion and participation in API specifications, focusing on OpenAPI, AsyncAPI, JSON Schema, GraphQL, and Postman Collections. My goal is to help increase awareness of these specifications, but more importantly get more people sharing what they are working on and invest more time and resources into supporting the specifications. I conduct an hour of informal discussions from 8:00 AM to 9:00 AM PST each Friday, and we record as many of our ideas and talking points on Github using issues. Some interesting ideas have emerged from the discussion, and I am taking some of the lowest hanging fruit from these ideas, organizing them, and working with the OAI, AsyncAPI, JSON Schema, and Postman team to try and bring some of these ideas to life.  There are many other ideas that didn’t make my starter list of project, but these are the ones I feel are the most important, would have the the greatest impact, and be achievable in small bursts of work, and to help drive some conversation I am having, I wanted to flesh out some of the top ideas here on the blog. I cleaned up the titles for each of these ideas, and grouped them based upon the type of project, and I would like to flesh out a little more, identify how they overlap and are related—then work to actually push them forward without me doing all of the work. I feel like with some assistance from the wider API community, and some investment from the OAI, AsyncAPI, JSON Schema, and Postman, these projects could make a pretty significant impact on what is going on across the API landscapes. My objective with this post is to show how all of these projects can feed each other, and see what I...[Read More]


API Evangelist

An API Lifecycle Collection Playbook

11 Nov 2020

I have a single API request that is becoming the first call I make on a growing number of Postman ccollections. It is a call to the Postman API to pull the OpenAPI for any API I am managing using Postman. This gives me the OpenAPI contract for an API so that I can move forward as part of a variety of stops along the lifecycle, starting with mocking, documentation, and testing as part of an API-first approach, but then also potentially monitoring, securing, generate client code, or even deployment and management of an API. I am working with a number of API service providers to define Postman collections that go well beyond the common APIs you will find in the Postman API Network, helping develop entirely new categories of collections that are designed to deliver different stops along the API lifecycle, so I am looking to develop a playbook for how you create one of these new types of collections, baking your API services into the Postman platform. Publish a Team Page Any partnership with an API service provider and the Postman platform begins with publishing of a team profile to the Postman network. Providing a logo, name, and description for your company, creating your official team profile on the Postman platform—here is my reference API implementation team page from the Postman API network.  You can manage your team profile under your team settings in your Postman dashboard. You can upload a logo, choose a name, and provide a description. When ready, you can choose to make your profile public, choosing a subdomain for your company on the Postman platform.  This is the profile for your API services on the Postman platform, accessible by 13 million developers via their desktop application and on the web. All the collections and template you publish for your services will show up here, and be discoverable via Postman and Google search, providing more exposure for the services you...[Read More]


API Evangelist

A Lifecycle for the API Factory Floor

10 Nov 2020

I am pushing forward a handful of conversations with enterprise organizations about how to better formalize their API lifecycle workflow. To help me load up my talking points in my head I wanted to publish a post here on the blog. Using Postman I am finally able to actually execute on my API lifecycle visions in the most tangible way since I started doing all of this in 2010. Postman is a Swiss Army Knife that allows me to approach the API lifecycle in a variety of ways depending on the situation I find myself in. While there are a lot of unknowns when it comes to doing APIs, there are also a lot of common patterns to use, and this is an exploration of these standardized approaches, allowing me to articulate them tomorrow during some discussions. Workspace It may seem obvious, but I am finding that having a well defined workspace to define, design, and manage APIs is essential to doing APIs well. Having a single place where you can find the contract and supporting artifacts that define each of the stops along the API lifecycle is needed to do all of this at scale, and consistently collaborate and move APIs forward. There are a handful of elements needed to define an API workspace when you are using Postman. Name - You'd be surprised at how important the name of an API can be when it comes to making it discoverable and usable by consumers--how you name your API will define a lot about it. Description - A well written description for an API is your first impression when it comes to onboarding consumers. They shouldn't be a novel, but it should provide enough information for a consumer to understand what it does. Administrative Team Members - Have your leadership team identified, make sure they are plugged in and know what needs to be done, giving them the control and observability they need. Collaborator...[Read More]


API Evangelist

Shifting How API Providers Define What An Application Is When Onboarding and Integrating With Their APIs

28 Oct 2020

When you sign up to access most APIs you will have to sign up for an account, create an application, and retrieve a set of keys and / or tokens before you will be able to use the API. This is standard practice that is baked into the home grown as well as Commercial API management solutions available across the landscape. This is a concept that was introduced back in 2005 by Mashery, and is something that hasn’t changed much over the years, despite what we build on top of APIs, and use APIs for having changed significantly over the last decade. In 2020, this relic of API management past needs to evolve if API providers and consumers are going to use APIs to their fullest potential—something API management service providers are going to have to take the lead on, and get back to work innovating and not just being a commodity. When I sign up for Twitter’s API I have to create an application before I can get the tokens I need to begin using the application. I have to provide a name, purpose, and other details about what that application is—even if I do not fully understand what that is. Most API provider’s notion of an application means web or mobile application, but in reality it can be the “application” of the data, content, and algorithms being made available via an API in a variety of ways from just pulling data to integrating in real-time with other systems. As an API analyst and storyteller I rarely am building an application, but just looking to kick the tires and understand what is going on—being forced to define an application is nothing but a road block for me. I may be a small group of API consumers, but there are many other edge cases which are similar to my situation in that we represent the long tail of API consumption in the unknown unknown API...[Read More]


API Evangelist

Providing Source Metadata as Part of the API.json Index for Data APIs

06 Oct 2020

The COVID-19 API resource center we launched back in April at Postman was a success. It generated a lot of traffic and API usage, but also brought in about 75 API submissions from the community. One of the things we learned as part of this work is that more APIs doesn’t always mean better outcomes. More APIs means they have to be properly described and tagged, making them more discoverable, but you also need to make they are all “good” APIs. Which, once you begin to dive in, you realize that it becomes quite a can of worms, but luckily we have the APIs.yaml specification to help us map things out in a way that allows to slowly evolve things from human to machine readable. When it came to the COVID-19 data APIs were were making available one key element of “good” was knowing a little more about provenance behind each of the APIs, helping us see the overlap between all of the APIs, as well as the unique outliers who were providing new and novel resources. First, to make sure everyone is up to speed, APIs.json / APIs.yaml is a simple machine readable index for defining collections of APIs, and mapping out API operations. In this scenario I am using APIs.json as the core of an API toolbox that runs 100% on GitHub using Jekyll and Github Pages. In addition to indexing the documentation and Postman collections for each API, I am adding a provenance property to help define where the data behind each API originate, producing YAML that looks like this. Right now the x-sources APIs.yaml property just provides an array of name and urls for each of the data sources behind each API. Mostly just providing a list of URL sources that can be displayed, but it is a property that could be evolved to provide more machine readable capabilities like grouped by domain, rating, public or private sector, and other things...[Read More]


API Evangelist

Machine Readable API Monitoring Using the APIs.json CASC Score Property

06 Oct 2020

I have been working with my friends over at APIMetrics on the COVID-19 and U.S. Election resource centers we launched recently. These API resource centers are all powered by an APIs.yaml index, providing a machine readable core that is used to power each API resource center single page application. Providing an index of a variety of COVID-19 and election related resources that powers the website, but also can be used in other applications and systems to pull the OpenAPI, Postman Collections, and other artifacts that are being made available. One of the artifacts I am layering into the listing for each API is a CASC score, showing the uptime and availability across all of the resources being made available, helping me float the best APIs to the top of each API resource center.  First, to make sure everyone is up to speed, APIs.json / APIs.yaml is a simple machine readable index for defining collections of APIs, and mapping out API operations. In this scenario I am using APIs.json as the core of an API toolbox that runs 100% on GitHub using Jekyll and Github Pages. In addition to indexing the documentation and Postman collections for each API, I am adding a property for a CASC Score which looks like this: CASC Score is a way to understand the reliability and maturity of an API from my friends over at APIMetrics. I just took their data and created a machine readable APIs.yaml property that I could then use to display the CASC score for each of my COVID-19 and U.S. Election APIs. Using the property to sort and display the CASC score as part of each listing. I needed a way to float the cream of each API resource center to the top, and the CASC score is one thing I consider when it comes to ranking each of the community contributed APIs. I am looking at other metrics, which I will also publish as APIs.yaml properties...[Read More]


API Evangelist

Talking About the Importance of API Specifications with Marjukka Niinioja (@mniinioja)

05 Oct 2020

One of the regular patrons of my weekly Friday open office hours around API specifications has been with API expert Marjukka Niinioja (@mniinioja), and a couple of weeks back we carved off 30 minutes to discuss the important of OpenAPI, other specifications, and the need for more education and awareness around specifications. I spend 30 minutes getting Marjukka’s view of the landscape, and more insight into why she thinks API specifications are so important, take a listen for yourself. What I like about chatting with Marjukka is that she gets APIs, especially OpenAPI, but more importantly she is passionate and motivate to contribute back to the community. I speak to many people about OpenAPI, AsyncAPI, Postman Collections, and JSON Schema, but finding folks like Marjukka who are driven to help document, tell stories, and help move things forward. Thanks for your time Marjukka, and if any of you readers want to learn more about what she is working on you can join us for the regular API Specification Toolbox office hours each Friday.[Read More]


API Evangelist

Why APIs Should Matter to You

20 Sep 2020

This is a talk I gave Saturday this last morning to almost 100 students in India, helping demonstrate the potential of APIs when it comes to their career. It is easy for me to stay entrenched in a world where everyone knows what an API is, but these types of conversations help me break out of the API echo chamber and reach out to developers, would-be developers, and those are curious enough to pull back the curtains on how the web works a little bit. With this talk I am looking to convert a few more folks to my API religion. Not because APIs are always good, but because being aware of the API layer that exists beneath our digital, and increasingly physical world is important. You will be more successful in both your personal and professional lives if you are API aware, and with this talk I am looking to help lay the foundation for anyone, developer or non-developer to understand the importance of API in our digital world. What is an API?  An API, or application programming interface is the current evolution of the web when it comes to making data, content, media, and algorithms available to different types of applications. Websites are written in HTML, and designed to be displayed to humans in our browsers. All you have to do is right click on any web page you visit and select view source to see the HTML behind any web page you are visiting. APIs provide access to the same data, content, and images used in websites, but instead of returning HTML, it returns XML or JSON which developers can render exactly as they wish in the application they are delivering. APIs are not some new software from one of the technology giants, it is just the next evolution in the web, making sure we can use deliver the same data, content, and algorithms across the applications we run on our laptops,...[Read More]


API Evangelist

I Am An Evangelist

19 Sep 2020

I have to write these posts every so often to help folks understand who I am and what it is I do as the API Evangelist. You see, there are regular streams of people who attempt to define me based upon their view of the world, their belief system, and reduce me to a know series of transactions that compute in their version of reality. In the tech arena there are several variations of what I do for living, going by a handful of labels; evangelist, advocate, relations, ambassador, champion, or some other word. None of these disciplines possess a formal definition, and are perpetually defined by the people who fill these roles. I am not in the business of defining what people do when they wear these titles, or generalize any of them as good, bad, nor neutral. They are just like tech in my experience, and are only as a good or bad as the human beings they serve, and I’m not really in a place where I give many fucks about policing any of this. However, when people say evangelists are doing bad things I tend to take offense, and sometimes feel compelled to put some words down within my domain (hrumph!). Technology and API evangelists existed before I came around in 2010, but after doing this a decade, and playing this part for enough time, I’ve earned the right to push back, and call bullshit on the shade being thrown in my direction.  First, I am an evangelist. I will even let my ego step up and say that I am The API Evangelist. I’ve put down my mark. Paid my dues. I’ve stayed the course for over ten years now, worked for the White House, with governments around the world, and most of the biggest names in tech in one capacity or another. Pure ego baby! I’m good with it. Ego is required to be in the role at this level....[Read More]


API Evangelist

FiveThirtyEight Shares the Election Data Behind Their Articles and Visualizations

11 Sep 2020

My partners in crime Metadata Technologies North America (MTNA) and I are working on identifying the best election data and API resources available today, and one of the gems out there, when it comes to what is available is out of the politics and sports data platform FiveThirtyEight. The data storytelling platform have made a name for themselves when it comes to predicting election outcomes, and possess some very interesting datasets around elections, which they public via a simple landing page, and on GitHub in a public repository. FiveThirtyEight Data Page - A simple page outlining all their data resources. FiveThirtyEight Data Repo - All the datasets they have in a single GitHub repo. FiveThirtyEight has general poll data, but also data for more precise questions like “How Popular is Donald Trump?”, and “Are Democrats or Republicans Winning the Race for Congress?”. They provide data as CSV files via their data page and on GitHub, making it easy to get at the data behind polling and storytelling. I am working with MTNA to take things a step further, and ingesting the data files and publishing them as simple APIs, then generating collections that index all the APIs, making it easier to access all the election related files in a single collection, while also opening up the possibilities for using Postman visualizer to make sense of the data being returned. Providing self-contained API client for all the data, complete with charts, graphs, and other eye candy that make it easier to understand what is happening. I really like the happening approach to publishing the data via their dedicated page because it is dead simple, providing a title, more info, and a CSV download, as well as column saying how long it has been since it was updated—down to the minute. Providing everything you need to understand what is going on with each dataset. This got me thinking about the real time opportunities involved with making the data available...[Read More]


API Evangelist

An OpenAPI and Postman Collections for the Census API

10 Sep 2020

I am including the U.S. Census API in a couple of different projects in the queue, and to help me make the API more discoverable and usable by developers I needed an OpenAPI and Postman collection for the API. Helping make it easier for developers to on-board with the Census API, but also provide a base collection I can use to develop additional workflow collections that help provide specific types of data easier to use in variety of use cases. Our data API partners over at Metadata Technology North America (MTNA) is helping us deploy APIs on top of some valuable datasets as part of our COVID-19 resource center, and they offered to help us develop the OpenAPI and Postman collection for the U.S. Census API. Carson Hunter (@carrrson) from MTNA got to work crafting an OpenAPI 3.0 for the Census API, providing a pretty robust source of truth for the API, which we can then use to generate Postman collections to document, mock, test, and automate around the Census API, but also just use the collection as a client for running different queues and saving the results of API responses to files without having to write code. Carson did the extra work of also creating a Postman collection and publishing as documentation, helping make the API a little easier to navigate, while also making sure there is a “Run in Postman" button available so that developers can quickly begin putting to work within their own Postman workspaces. Carson helped reduce the friction when it comes to onboarding with the Census API, while also helping me make it more discoverable as part of the various API projects I am working on. There is a lot more work we can do on these reference OpenAPI and Postman collection, but we wanted to just pause and put out there for others to comment on what they would like to see. We have published the OpenAPI and Postman...[Read More]


API Evangelist

Smoothing the Rough Edges Off Serverless with Nimbella

09 Sep 2020

One of my current tasks at Postman is to help explore what the future of API deployment looks like. When I went into this work I expected serverless to play a significant role, but I have to admit I didn’t anticipate the ways in which serverless would be used to reduce the steps it takes to actually deploy APIs. One of the tools I have been playing with for a couple of months now is Nimbella, which describes itself as “the simplest way to build and run serverless applications”. I spent significant amounts of time building collections for deploying APIs to AWS using Lambda earlier this year, so when I had an API deploying in just a couple of minutes with Nimbella, you can say I was pretty impressed with what they have done to serverless by making it easy, but also bringing in the critical ingredients you need to actually deliver meaningful apps. Nimbella is free to get started. Once you have logged in you can fire up your first project within 60 seconds, after installing the Nimbella CLI for Mac, Windows, or Linux. Once you have the CLI installed you can just execute: nim auth login [your token]  This command, plus all three runtimes are available on the home page of you account once you have signed up--then you can choose to install a single one of their start projects with: nim project deploy github:nimbella/demo-projects/qrcode nim project deploy github:nimbella/demo-projects/visits nim project deploy github:nimbella/demo-projects/ocr nim project deploy github:nimbella/demo-projects/chat Or you can go ahead and clone all of their demo projects, which I recommend, because it allows you to reverser engineer a whole suite of simple serverless micro applications: git clone https://github.com/nimbella/demo-projects Within five minutes you can be reverse engineering what is possible when you deploy APIs and/or applications with Nimbella. With each Nimbella project you begin with two folders locally on your machine, the power your implementation: Functions - This is the functional API...[Read More]


API Evangelist

Generating a Serverless API in Multiple Languages From a Postman Collection

09 Sep 2020

I am continue my storytelling around the work I am doing with Nimbella to help define what the future of API deployment looks like from within Postman, and next up on my list to do some storytelling around the Nimbella Postman Plugin, which allows you to deploy the server-side scaffolding for an API in seven programming languages from a Postman collection. Nimbella is a dead simple way to deploy serverless APIs and applications, which also possesses a plugin infrastructure that lets you extend the platform, and one of the plugins the Nimbella team has developed allows you to design your APIs using a Postman collection, then generate your serverless API project in Go, Node.js, Typescript, Python, Java, Swift, or PHP.  Once you have signed up and logged into Nimbella, and installed the CLI for the platform, you can add the Postman plugin at the command line using: nim plugins add postman You can find the Postman plugin for Nimbella on Github if you are looking to take things to the next level, but installing it is pretty dead simple with the one CLI statement. You can find all the usage options available for the Nimbella Postman CLI plugin on the GitHub README, but here is a basic command that will generate an API project from any of your Postman collections. nim project create -s postman -i Products --language js This creates a new local Nimbella API project for me using a Postman collection in one of my Postman workspaces simple named “Products” in JavaScript. As soon as I want this API to be available in the cloud, I simply run this command: nim project deploy . Now I have my API. Of course I will still have to wire up the API to any actual database, functionality, or 3rd party AP or system I will be working with, but it gives me the skeleton of my serverless API in seconds—all originally defined in Postman as a...[Read More]


API Evangelist

Not Being Able to Post to My Facebook Feed Using the API

03 Sep 2020

I am hung up (once again) on the fact that I can’t post to my personal Facebook feed via the Graph API. Facebook removed the ability for you to add or update to your Facebook feed via the API in 2018. You can still post to pages via the API, but are out of luck via your personal profile. It drives me nuts because I queue, schedule, and automate a significant amount of my online presence. Honestly Facebook doesn’t do much for my personal or professional online presence, but the fact that I can’t do it is driving me nuts. I have an idea I want to implement around telling stories on Facebook, and without the ability to post via the API, the idea is a non-starter. I really bothers me when I can POST or PUT to any platform I depend on, and the fact that it is Facebook drives me even more nuts, making it something that I just can’t seem to put down. Posting to My Facebook Wall Using Postman While you can’t officially add to your feed via the official Facebook API, you can using Postman. You can install the Postman Interceptor Chrome extension, proxy traffic, and isolate the API call you need to post to your feed, including all the configuration and cookies you will need to make it work. I will write a separate post that walks through how to do this, but I just want to think through all of this before I move forward teaching other people how to do this. Like most everything with APIs, this isn’t just technical, and there are numerous business and political considerations to flesh out before I just plow forward teaching everyone how to circumvent Facebooks limitations. I am not sure I want to me sharing this knowledge, let alone polishing the rough edges so that it is something that a wider audience can implement. You see, APIs are neither good,...[Read More]


API Evangelist

Twitter OpenAPI, Docs, and Mocks in a Workspace

02 Sep 2020

I am working on several demonstrations of what is possible when you use OpenAPI on the Postman platform, and as part of this storytelling I want to use the OpenAPI of leading API platforms to demonstrate what is possible. I am looking to showcase the potential of using an OpenAPI as a base of the API integration and development lifecycle, and today I wanted to showcase what you can quickly do when you put the OpenAPI for the Twitter API into a Postman workspace. This OpenAPI can act as the truth for a variety of lifecycle activities, but to begin with I usually generate two collections. One for providing reference documentation for the entire API, and another to provide me with a mock representation of the entire surface area of the API, helping me articulate what the API does to team members, while also kicking the etires on it before I have to obtain a token or key. This approach isn't unique to the Twitter API, and can be used by API providers to guide the development of APIs, or it can be done by API consumers to help localize documentation, mock servers, and other resources you will need to work with an API. If you want to see it in action you can walk through a short video, showing how you can do this in just a few minutes using Postman. [Read More]


API Evangelist

Stripe OpenAPI, Docs, and Mocks in a Workspace

02 Sep 2020

I am working on several demonstrations of what is possible when you use OpenAPI on the Postman platform, and as part of this storytelling I want to use the OpenAPI of leading API platforms to demonstrate what is possible. I am looking to showcase the potential of using an OpenAPI as a base of the API integration and development lifecycle, and today I wanted to showcase what you can quickly do when you put the OpenAPI for the Stripe API into a Postman workspace. This OpenAPI can act as the truth for a variety of lifecycle activities, but to begin with I usually generate two collections. One for providing reference documentation for the entire API, and another to provide me with a mock representation of the entire surface area of the API, helping me articulate what the API does to team members, while also kicking the etires on it before I have to obtain a token or key. This approach isn't unique to the Stripe API, and can be used by API providers to guide the development of APIs, or it can be done by API consumers to help localize documentation, mock servers, and other resources you will need to work with an API. If you want to see it in action you can walk through a short video, showing how you can do this in just a few minutes using Postman. [Read More]


API Evangelist

GitHub OpenAPI, Docs, and Mocks in a Workspace

02 Sep 2020

I am working on several demonstrations of what is possible when you use OpenAPI on the Postman platform, and as part of this storytelling I want to use the OpenAPI of leading API platforms to demonstrate what is possible. I am looking to showcase the potential of using an OpenAPI as a base of the API integration and development lifecycle, and today I wanted to showcase what you can quickly do when you put the OpenAPI for the GitHub API into a Postman workspace. This OpenAPI can act as the truth for a variety of lifecycle activities, but to begin with I usually generate two collections. One for providing reference documentation for the entire API, and another to provide me with a mock representation of the entire surface area of the API, helping me articulate what the API does to team members, while also kicking the etires on it before I have to obtain a token or key. This approach isn't unique to the GitHub API, and can be used by API providers to guide the development of APIs, or it can be done by API consumers to help localize documentation, mock servers, and other resources you will need to work with an API. If you want to see it in action you can walk through a short video, showing how you can do this in just a few minutes using Postman. [Read More]


API Evangelist

Atlassian OpenAPI, Docs, and Mocks in a Workspace

02 Sep 2020

I am working on several demonstrations of what is possible when you use OpenAPI on the Postman platform, and as part of this storytelling I want to use the OpenAPI of leading API platforms to demonstrate what is possible. I am looking to showcase the potential of using an OpenAPI as a base of the API integration and development lifecycle, and today I wanted to showcase what you can quickly do when you put the OpenAPI for the Atlassian API into a Postman workspace. This OpenAPI can act as the truth for a variety of lifecycle activities, but to begin with I usually generate two collections. One for providing reference documentation for the entire API, and another to provide me with a mock representation of the entire surface area of the API, helping me articulate what the API does to team members, while also kicking the etires on it before I have to obtain a token or key. This approach isn't unique to the Atlassian API, and can be used by API providers to guide the development of APIs, or it can be done by API consumers to help localize documentation, mock servers, and other resources you will need to work with an API. If you want to see it in action you can walk through a short video, showing how you can do this in just a few minutes using Postman. [Read More]


API Evangelist

A Diverse API Workspace Example Using OpenAPI and GraphQL From GitHub

01 Sep 2020

Like other successful API patterns REST and GraphQL have been in competition for mindshare since GraphQL emerged on the landscape. GraphQL folks love to say it is a replacement for REST, and the RESTafarians love to point out GraphQL’s weaknesses. When in reality they are both very useful patterns that API providers and consumers should be aware of, and possess in their API toolboxes. In an effort to continue showcasing the importance of having a diverse API toolbox, I wanted to take a walk through my GitHub API workspace, which I use personally, but wanted to take a spin through it to help polish some of the rougher edges of my approach, before I invite some other team members to use my workspace. An OpenAPI and GraphQL Core While I have many orphan API collections laying around in workspaces, my more robust workspaces tend to leverage OpenAPI as the truth of each API, but with the GitHub API I have the opportunity to provide both an OpenAPI and GraphQL API side by side in a single workspace. Providing me with the base for all of the collections I am generating, evolving, and making work for me when integrating, automating, and orchestrating with the GitHub API. GitHub V3 OpenAPI - GitHub maintains an OpenAPI definition for their web API, allowing anyone to use as the base for generating docs, mocks, tests, and integrate, automate, and orchestrate across the API lifecycle. GotJib v4 GraphQL - I pulled the schema definition language (SDL) for the GitHub GraphQL, and published it as an API, which I can then use to generate collections—there is only a single endpoint, but still provides me with a base. These two API contracts provide me with a machine readable description of what is possible when it comes to working with the GitHub API. However, both of these require you to be fluent in OpenAPI and / or GraphQL to be able to get what...[Read More]


API Evangelist

The Current State of Mock APIs Using Postman

31 Aug 2020

One of the teams I work closely with at Postman is the group behind mocking APIs with Postman. The ability to statically mock APIs has received a lot of investment when it comes to recent releases, and in a couple of my Postman partner conversations I have been asked for more information about how to mock API using Postman. So, in an effort to reach the widest possible audience as I can, I wanted to write up an overview on the current state of mocking APIs using Postman, to help get everyone up to speed—including myself. ;-) Overview of Mocks Using Postman To get started with understanding the value of mocking APIs I recommend visiting the dedicated marketing page Postman has up for mocking APIs. This provides you with the meat of what you’ll need to make the argument for mocks across your team, as well as your leadership. See Exactly How Your API will Run—Even Before It's in Production - API design is the key to building quality APIs that last. Postman's mock API servers simplify design and planning, support split-stack development, and help you ensure that your API will run the way it's supposed to in production. Shorten Time to Production - Work more efficiently with Postman's API mock servers. Postman mocks support split-stack development so front-end and back-end developers can work in parallel and view responses without spinning up the back end. Design Your API with Flexible Schema Support - Postman mock servers complement Postman's extended schema support. Write, edit, or import your API schema to define your API's data structure and generate a collection from your API schema. You can review API responses using mock servers so you can reliably build your API from the ground up—all in one central place. Simulate the Expected Behavior of Your API - Postman Mock Servers simulate API responses that applications and services can utilize even before the API is built. Postman matches requests and...[Read More]


API Evangelist

A Diverse API Toolbox is the Future

31 Aug 2020

One of the reason you always want to surround yourself with people who call bullshit on meaningless trends is that when you begin to fall under the spell of each wave of API blah blah blah, they will slap you upside the head and remind you what this is all about. This happened to me the other day when I mistakenly mentioned that the future of APIs is event-driven, and Fran Méndez (@fmvilas) from AsyncAPI slapped me upside the head and reminded that the future is about possessing a diverse API toolbox, allowing you to apply just the right approach to APIs for the job. Making sure we are equipped to deliver useful and meaningful APIs, not just the latest API blah blah blah because we heard it was cool somewhere. HTTP APIs, or as they are often referred to as REST APIs, are always the base layer for any API operation. This is where everyone should begin, but there are a number of other healthy patterns in use that teams should be aware of, and able to confidently implement. I began working working on this narrative back in March of 2017 with a Focus on Having a Robust and Diverse API Toolbox, which is something I kept expanding on in January of 2018 with My Evolving Definition of a Robust and Diverse API Toolbox, culminating in a talk that I gave at API Days Paris about APIs Not Just Being REST. I am thankful for Fran slapping me and reminding me that I shouldn’t fall under the spell of any single API design pattern, and that a diversity in learnings and implementations is critical to being successful in the API long game. REST, SOAP, Hypermedia, GraphQL, WebSub, Kafka, and many other successful API patterns dot the landscape. REST is dominant because it is simple and reflects the web, but as many practitioners point out, it will begin to fail you in a variety of...[Read More]


API Evangelist

The Evolving World of API Discovery

27 Aug 2020

The discovery of APIs has been the single most significant issue I’ve tracked on and contributed to over my career as the API Evangelist. It is also one of the stops along the API lifecycle I have been very frustrated with due to a lack of things moving forward over the last decade. While there has been many failed attempts at folks trying to bring new API solutions to the table, the conversation really hasn’t gone anywhere. That is, until the last couple of years, where we are seeing a new crop of interesting API service providers who are looking to address API discovery in new and interesting ways, bundling the discovery of APIs with other functions that help speak to the business bottom line, going well beyond just searching for APIs across the enterprise, or on the open web. I am tuned into a handful of new API focused startups who are coming at API discovery from a variety of angles, but one of them I have been meeting with weekly to discuss the importance of API discovery, but also API governance, is with the folks from TeejLab, who provide a view of the API discovery landscape through the enterprise risk management lens. TeejLab’s API discovery solution isn’t some API catalog or search engine, they help you discovery APIs across your existing operations, then evaluate and better manage how they are put work moving forward. Helping enterprise organizations find the existing internal, partner, and public APIs they already depend on is the #1 challenge enterprise organizations face right, and it is a problem that is only going to exponentially get worse in coming years. This is what makes TeejLab’s so relevant, in that they don’t just help you discover your APIs so you can use them, they help you assess the security, privacy, licensing, and other risks that come with unmanaged, ungoverned API chaos that exists across most enterprise organizations today. When it comes...[Read More]


API Evangelist

An API Toolbox Blueprint

26 Aug 2020

I was needing a simple way to move forward a variety of API conversations I am having, ranging from COVID-19 APIs to API service providers who are using OpenAPI. I need a quick way to be able to flesh out a list of APIs, tooling, and specification that can be leveraged by developers when it comes to tackling a specific problem within an industry, issue, or conversation. This is an evolution in our strategy for shining a spotlight on the COVID-19, helping me better figure out how we can keep adding value to the COVID-19 discussion, but also quickly do the same in other areas. For the COVID-19 effort we threw up a landing page and GitHub repository back in March, and since then we’ve seen some pretty interesting submissions and conversation come out of the community. Improving Upon the COVID-19 API Resource Center The COVID-19 API Resource Center is a listing of Postman API collection we’ve developed, curated, and accepted from the community.  We seed the resource center with 15 collections, and received 36 collections from the community, with 25 submission awaiting for a Postman collection to be developed so the API can be added to the list. For a total of 51 collections available on the COVID-19 resource center, providing a range of resources from data on COVID-19 cases and deaths to drugs and testing information. We successfully used GitHub to accept community submissions via issues, and evolve a pretty robust list of resources, but some of the APIs and resulting collections were of higher quality than others, and I wanted to understand why. To help me understand I went through all of them identifying the areas the could use more investment when it comes to helping individual collections, as well as the overall toolbox of collections, better serve the mission to help us in the COVID-19 fight. Narrative - Collections that do not have a descriptive title, or robust and helpful enough...[Read More]


API Evangelist

Getting More Hands-On Talking About API Governance

17 Aug 2020

I am getting more hands-on with my API governance guidance while working at Postman. It is one of the reasons I joined the company, so I could move more into the execution of my API lifecycle strategies, which also includes applying API governance. To showcase some of what I have been developing I am doing an API governance webinar this Wednesday. To help me polish the narrative around my talk, as well as my wider API governance guidance, I wanted to work through my current narrative here on the blog. What I am enjoying most about my narrative right now is that they are rooted in doing what I am talking about, allow me to get more hands-on with API governance, where for much of the last five years my stories have just been narratives without much meat on the bone. I am enjoying this shift from a more academic perspective to actually being able to deliver what I am talking about when I say API governance. An Intro API Governance Most people will go straight to API design governance when they begin talking about governance, but I prefer starting with the base of API governance that is already in motion across many API operations. Born out of an API-first approach to delivering infrastructure many teams are already delivering on governance, they just call it other names like versioning and contract testing. This is definitely the road to API governance, but it is lacking an overarching API governance strategy to effectively deliver across many different APIs developed by many different teams. To help paint the tactical API governance that is already occurring let’s zoom in on a single API being developed using an API-first approach, and consider how it is laying the foundation for a wider and more strategic approach to governance how APIs are delivered.  Workspace - Having a dedicated repository and / or workspace for an API provides the base for delivering APIs...[Read More]


API Evangelist

I am Giving a Workshop on API Testing to Computer Science Students at Tecnológico de Monterrey Tomorrow

13 Aug 2020

I am giving a presentation to my friend Ken Bauer Favel's (@ ken_bauer) class of computer science sutdents at Tecnológico de Monterrey (@TecDeMonterrey) tomorrow, and I wanted to prepare an overview of what I am going to be talking about, and share some links for the students to follow. I am doing more workshops with students recently as part of Postman student outreach, and Ken’s class is exactly the target audience we are interested in reaching. These are young minds who are just getting started in their careers and they should be aware of APIs, how to put them to work, but more importantly making sure they are fully tested and reliable for consumers, and the applications that are built on them. Ken’s class is all about software quality and testing, so I figured I would take a look at how APIs can be defined, versioned, managed, and tested. I’ll be showing them the process using Postman, which is a ubiquitous tool for developers within the enterprise but the concepts I'll demonstrate are universal an something the students can apply using different tooling, using any HTTP API. Here are the building blocks of what I’ll be walking them through, with some links to help them get primed if they have the time. API 101 - A quick refresh about what APIs are, and acknowledging they are behind every technological shift of the last 20 years. History of APIs - A quick look at how we got here, and the role that APIs play in modern software development. Introduction to Postman - Learning about how Postman can be used to make calls to web APIs without writing code. OpenAPI (formerly known as Swagger) - Looking at how OpenAPI can be used as the contract for each API, providing a machine readable definition for each API. API Authorization - Taking a moment to understand how APIs employ authentication, and how Postman can help you apply common forms...[Read More]


API Evangelist

Location-Aware Local Commerce Open Source API Standard From Beckn

11 Aug 2020

I am working on profiling open specifications as part my work at Postman to help highlight how we can deploy APIs that use a common API and schema, reduce friction when on-boarding, while also increasing reusability across different industries. One of the open specifications on the table is from Beckn, who offers a suite of open source API specifications for things like food delivery, healthcare, and transportation--here is the description from the Beckn website describing the value they deliver. Beckn is an open protocol that enables location-aware, local commerce across industries to be discovered and engaged by any beckn-enabled application. Beckn, while being a minimal open source protocol specification, acts as a force multiplier for end-beneficiaries - customers, application developers, governments, and businesses by creating an interoperable open playground to unlock value and innovation I love to see these kinds of projects. My concern is always heldping ensure they get enough adoption to help sustain them, and contribute by helping evangelize the possibilities, which is why I am writing this post as I am working with the Beckn team to get the word out about their standard. To help push forward the conversation forward around the Beckn APIs I need Postman collections for the platform, or even better…OpenAPI definitions so that I can generate Postman collection—luckily Beckn is developing their API protocol out in the open on GitHub using OpenAPI, making my job easy.  To help me move things forward I created a workspace in Postman dedicated to Beckn, then I took five of their OpenAPI definitions and published to the workspace, allowing me to use Postman to manage the collections and resulting docs, mocks, and eventually tests for the APIs. Right now I am just interested in helping the Beckn team better understand how they can manage their OpenAPI definitions using Postman, then sync the definition for each API bck to the GitHub repo they have setup. Then they can generate collections from the...[Read More]


API Evangelist

Postman API Governance Collections

03 Aug 2020

I have been moving forward a number of new types of Postman API collections as part of my Union Fashion reference implementation at Postman, and one of the new types I'm using as part of different conversations are my API governance collections. I have two collections I am moving forward as a proof of concept (POC), helping map out how collections can be used to not just provide and consume APIs, but also help make sure they are more consistent in how they operate. Governance (Design) - This is just the governance of the design of the API, and since this is what most folks think of when they talk about API governance, it is the place most people should start this conversation. Governance (Lifecycle) - This is for the governance of the entire API lifecycle from start to finish, really helping me push the boundaries of what a collection is for, but also how we provide guardrails for our APIs. The API design governance collection is interesting for me, but pushing myself to think about what API governance looks like for the entire lifecycle has helped me see things differently, and has allowed me to realize that you can't govern what you don't have defined, and aren't measuring.  Some Initial Thoughts This is all still a work in progress, so I am still working to make more self-service, and something anyone can put to use as part of their operations. Here is my brain dump of thinking going into this work, which will hopefully articulate a little more about where I am at with the work and how you can help provide feedback and thoughts on where I should go next. Why Collections? - I am skeptical that any software should bake in "governance" features into their product as governance means different things to different folks, and while we can come up with a standard set of rules that will fit most enterprise organizations,...[Read More]


API Evangelist

Managing Your OpenAPI and Postman Collection Publicly

02 Aug 2020

I am having this conversation with multiple API providers right now, so I wanted to write it up, share it as part of these conversations, while also making it available for my wider audience here on API Evangelist. This is a blueprint for managing the OpenAPI and Postman collection in a very public way, ensuring the machine readable definition for an API is discoverable and easy to access, while also establishing a feedback loop for the community to participate in helping define the roadmap for each API. Leveraging both Postman and GitHub to move an API forward in a much more collaborative and observable way. Establishing a Postman Workspace ssThis blueprint begins with establishing a team workspace in Postman for managing the OpenAPI, and any collections that are derived from the OpenAPI contract, as well as environments that will be used to abstract away tokens, secrets, and other key / value pairs needed for working with the API.  The Postman workspace will become the source of truth for your APIs, which can then be used to power other stops along the API lifecycle. You can have a single API in a workspace, or have multiple APIs, it is up to you how you want to organize your workspaces. The goal is to just make sure there is one place you can go to find your APIs, and work with other internal stakeholders on our team to move an API forward. Leveraging the workspace, but also all the comments, history, change logs and other features, helping you get more organized about how APIs are being delivered.  Adding OpenAPI to Postman Builder With a workspace you can now add your APIs using the Postman API builder. Each API allows you to publish an OpenAPI, establishing the central truth for each of your APIs, which we can then use to generate collections for powering stops along the API lifecycle, manage change with version, the change log, and history....[Read More]


API Evangelist

Managing the API Lifecycle Using OpenAPI and Postman

02 Aug 2020

I am having this conversation with over five separate API providers right now, so I wanted to write it up, share it as part of these conversations, while also making it available for my wider audience here on API Evangelist. I just finished another piece on managing your OpenAPI and Postman collection publicly, laying the foundation for this post. I want these to be separate modules which people can follow and use independently, providing me with a single URL for different concepts I am discussing. While this isn’t a a pattern everyone will want to follow, it is one possible pattern I’ve been identifying for use by companies looking to get a handle on how APIs are being delivered across the enterprise using Postman. Building on an OpenAPI Foundation The foundation of this blueprint is all about having an OpenAPI definition within a workspace acting as the central contract for each API. Providing the cornerstone each API will need to be moved along its lifecycle, and iterated upon by all stakeholders who have access to the workspace. You can view the separate post I have on management of OpenAPI using both Postman and GitHub, but here are the moving parts of what I propose for one possible blueprint for how you want to manage your individual APIs. Workspace - Always having a dedicated workspace for each individual API or a bundle of APIs, providing a single place internal stakeholders can find whatever they need about each API to understand how it works, and influence the road map when it comes to the future iterations. Repository - Ensuring there is a GitHub repository in place to act as the partner (private) or public face of each API workspace, providing a single place that external stakeholders can can to find information on APIs, and provide feedback on each API being made available. OpenAPI - There is a versioned OpenAPI contract in place for each API, publishing one...[Read More]


API Evangelist

Leveraging FastAPI to Deploy APIs in the Postman Ecosystem

30 Jul 2020

I am doing deep dives into each stop along the API lifecycle, beginning with deployment and management, to better understand how we can bring other features into Postman, without actually developing the features ourselves. There are two primary ways we are accomplishing this, by identifying open source solutions, and by partnering with services and tooling providers. Next up on my list is to flesh out is how we leverage the FastAPI framework as part of the Postman platform, helping developers deploy their API using the “ high performance, easy to learn, fast to code, ready for production” FastAPI framework. If you aren’t familiar with FastAPI, it is one of the top open source API frameworks on Github. It is built in Python 3.6+, and based on standard Python type hints. Taken directly from the web page for FastAPI, the key features are: Fast: Very high performance, on par with NodeJS and Go (thanks to Starlette and Pydantic). Fast to code: Increase the speed to develop features by about 200% to 300%.  Fewer bugs: Reduce about 40% of human (developer) induced errors. * Intuitive: Great editor support. Completion everywhere. Less time debugging. Easy: Designed to be easy to use and learn. Less time reading docs. Short: Minimize code duplication. Multiple features from each parameter declaration. Fewer bugs. Robust: Get production-ready code. With automatic interactive documentation. Standards-based: Based on (and fully compatible with) the open standards for APIs: OpenAPI (previously known as Swagger) and JSON Schema. I know that most Postman customers will care about all of those bullet points, but the one that really grabs my attention is the last one, and the fact that it is centered on the OpenAPI specification. As part of my OpenAPI Initiative (OAI) DemanGen efforts at Postman, and my work to flesh out different stops along the API lifecycle, I am interested in amplifying what FastAPI delivers, and work to further bake it into the Postman ecosystem. Allowing developers to rapidly...[Read More]


API Evangelist

A Very Useful COVID-19 Data Collection and Visualization

30 Jul 2020

This is a repost from the Postman community on a very slick COVID-19 data project with accompanying Postmn collection to actually work with the data and get back responses, and then view responses as a visualization using the Postman visualizer. Here is what was posted by Carson Hunter (@carrrson) from Metadata Technology North America (MTNA). We’ve been hard at work building our Rich Data Services COVID-19 project 4 and are excited to finally be releasing it to the public and to have our API included in the Postman COVID-19 API Resource Center. The API includes a free-to-use and always-expanding catalog of curated COVID-19 data and metadata that’s all set up to use with the Postman collection. (Docs are here 2, or run it with the button below.) The API has a lot of great features for querying and packaging data, but maybe the coolest thing of interest to the Postman community is the ease of integration with charting libraries, so you can create visualizations quickly and easily. In this collection, we’ve focused on using amCharts, but RDS also supports Plotly and Google Charts if that’s your thing. By specifying one of these libraries in the request, the API returns the data in a format that’s directly consumable by the library, so you don’t have to worry about manipulating the response. We’ve included some visualization examples from the collection below, but the amCharts library is vast and there is a lot of COVID data out there, and we would love to see any creations the Postman community comes up with using the API. You can tweet us at @mtnaus. Cheers! Create a bar chart comparing positive and total covid tests by state:  Create a line chart comparing covid cases between countries: We had a lot of COVID-19 collection submitted as part of the work we've been doing on the Postman COVID-19 Resource Center, and this is one of the most useful we've received, but it is definitely the best because it provides visualizations,...[Read More]


API Evangelist

Understanding How ShipEngine Manages Their APIs Using Moesif

29 Jul 2020

I am working to better understand the Moesif Analytics API so that I can define a new type of Postman collection I am calling an API management collection. You wouldn’t use this collection to make calls to an API you operate, you would use it to automate and orchestrate the API management layer you use to operate your APIs. I am working with several API management providers, but Moesif came up in my queue of work, and I feel they represent a more progressive view of the API management landscape, so I got to work pushing this conversation forward. I recently worked to create an OpenAPI and Postman collection for the Moesif API, so that I can better understand what they offer, and now I want to learn how some of Moesif’s customers are using their APIs, and ShipEngine was kind of enough to work with Moesif and me to help define an API management blueprint based upon how they manage their API infrastructure. ShipEngine uses both Postman and Moesif, so they provide a pretty compelling blueprint for modeling my API management collection after.  I am looking to better understand which of the 12 Moesif resources they put to work using the Moesif API, so I can plan the next big of work on this partnership effort. Actions - Understanding the context in which actions are tracked. Applications - Understanding more about the context of an application. Cohorts - Standardize how analytics are being organized by cohort. Companies - How companies are being managed using the API. Dashboards - What sort of dashboard orchestration and automation occurs. Events - Looking at what events are being surfaced and are meaningful. Health - How is overall health of the APIs being monitored and responded to. OAuth - What sort of authentication and authorization is being automated. Search - Understand how searching of companies, users, and events is done. URL Encoder - I’d like to understand more about...[Read More]


API Evangelist

Producing a Postman Collection for Mulesoft API Manager and Platform

29 Jul 2020

I am making my way through all of the partner conversation I am having, publishing stories for each of the conversations to help me move each one forward. Today I am focusing on API management providers because I am looking to define a baseline set of resources across all providers to consider for deeper integration, and of course storytelling. I’ve been talking with the Mulesoft folks since last year, working to find some ways we can partner and provide value for both of our customers. As with every other partnership, and especially API lifecycle partners, everything begins as a collection. If I can’t get at the APIs behind a service, create an OpenAPI and Postman collection for the API, then it isn’t an API lifecycle capability I can think about for deeper integration, and further storytelling. But Mulesoft isn’t messing around, and they have Swagger and RAML available for all of their API lifecycle services and tooling  I downloaded the generated Swagger 2.0 definitions Mulesoft provides for their API manager and API platform. There are some other interesting APIs available there that I would like to see live as Postman collections. Honestly, I’d like to see all of the APIs they have published via the Mulesoft // Dev catalog in the Postman API network, as well as Postman collection added to the dropdown list Mulesoft provides for each API, allowing it’s definition to be downloaded as RAML, Swagger, or Postman Collection. As with the other API management service providers I am profiling as part of this work, I created a Postman workspace for managing Mulesoft APIs. With the Swagger 2.0 and Postman collections for the Mulesoft API Manager and API Platform I can begin to break down the individual capabilities that the API management solution provides. Then I can pick from the most common of these API management building blocks and get to work developing some collections that help API providers automate and orchestrate the...[Read More]


API Evangelist

Developing a Reference OpenAPI and Collection for the Moesif Analytics API So That I Can Build an API Management Collection

29 Jul 2020

I am working my way through profiling API analytics provider Moesif. I have a pile of partner related work accumulating and there is no better way to work through what is going on than just writing here on API Evangelist—it is what this blog is all about. I am interested in Moesif because they are a next generation API management provider that represents the ever expanding universe of what we need to manage our APIs at scale. With the consolidation and commodification of API management since 2015, we’ve seen more specialized API service providers emerge like Moesif who are focused on just one aspect of management—like analytics. My review of any API service provider always begins with looking at their own developer area, and identifying whether or not they have an API (all API service providers should have APIs)—Moesif has one. Next, I need a machine readable API definition—either an OpenAPI or Postman, ideally both, as they have varied but overlapping purposes. Moesif is using Postman, which I will talk about more in a bit, but alas there wasn’t an easy OpenAPI or Postman collection for me to put to work (shame shame). Luckily they use Slate for their docs, which always means there is some easy to scrape and parse markdown or HTML right behind things. I quickly generated an OpenAPI for the Moesif API analytics API. It isn’t a complete OpenAPI, but it does give me the paths, summaries, and parameters in a machine readable format. I can use this to generate a Postman collection, then begin using it to certify each of the endpoints, saving examples, and making for a more robust definition for docs, mocks, testing, and other lifecycle stops. To continue working with my Moesif OpenAPI definition I will need to create a dedicated workspace in Postman for my work with this partner, and publish the OpenAPI in my Postman API Builder. With the entry level OpenAPI in Postman, I...[Read More]


API Evangelist

Breaking Down the Capabilities of the WSO2 API Manager

29 Jul 2020

I am profiling a number of API management APIs right now and reaching out to each of their teams to discuss moving forward a set of official API management collections that I can have published to the API network, and use to flesh out more API lifecycle capabilities within the Postman platform. Postman isn’t an API management service provider, so it make sense for us to expose existing API management and gateway solutions as integrations, rather than attempt to build anything on our own, partnering with the best of breed API management solutions already in use. This will be our approach to other stops along the API lifecycle, weighing the possibilities with each stop, based upon what already exists in the space, and what the opportunities are for us to build, partner, or a mix of both. Next up on my list of API service providers is to profile and assess as part of this work is WSO2. I’ve worked with WSO2 since way back in 2012, so I am somewhat familiar with their product and services. As with all of the other API management providers I am profiling I am looking for an existing OpenAPI or Postman collection to help me understand what is possible with each API. It was pretty easy to find the Swagger file for each of the WSO2 publisher, store, and administrative APIs, but I couldn’t easily find them for their tokens or analytics API, or their Microgateway—I will ping them to see if they have Swagger for these. I was able to upload three Swagger 2.0 definitions into a Postman workspace—I normally would upgrade to OpenAPI 3.0, but since these were provider managed specs I will keep them as is, in case I need to update. There are a wealth of resources available across these three WSO2 API, and having them available as Swagger definitions, and generated Postman collections helps me make sense of what is possible. This provides...[Read More]


API Evangelist

OpenAPI 101: Intro to OpenAPI (Open Office Hours Each Friday)

22 Jul 2020

It can be difficult to understand exactly what OpenAPI is and what it isn’t sometimes. I get a lot of questions from folks who don’t entirely grasp what the OpenAPI specification is, and how it applies to the API lifecycle. It is alright to not fully get all the technical details of the specification, and I want to acknowledge this deficiency in the space, and help address the challenges by holding a 30 minute open office hours where I will introduce what OpenAPI is each week--helping on-board new people to the world of OpenAPI. These discussions will start out pretty free form, with me developing some curriculum to help introduce folks to the spec, but is something I would refine each week based upon the questions I get from the public. I am looking to begin with just walking through some of the most common elements of OpenAPI 3.1, helping lay the foundation for what OpenAPI is all about:s History - Quick recap of how we got here, including the difference between Swagger and OpenAPI. Purpose - A look at what OpenAPI is for and why it has become a standard for defining APIs. Objects - Walking through the core objects that are present as part of the OpenAPI spec. YAML / JSON - Talking about how you can use YAML or JSOn to define your OpenAPIs. Services - Looking at some of the services that have adopted the OpenAPI spec as standard. Tooling - Looking at some of the open source tooling that have embraced the OpenApI spec. I think that is all I will have time for when it comes to the 30 minutes. Initially I’d like to just run through the basics of OpenAPI, and I can do 30 minutes sessions dedicated to other sections in future office hours. Right now I am looking to just talk about the basics, formalize some basic content, and answer the questions of folks looking to...[Read More]


API Evangelist

OpenAPI 101: Migrating From Swagger to OpenAPI (Open Office Hours Each Friday)

22 Jul 2020

OpenAPI has been around for five years now. There really is no reason for so many folks are still talking about Swagger 2.0, when there are more benefits associated with the OpenAPI 3.0 specification, and more modern services and tooling that utilizes the current version of the API specification. I want to open up a conversation about this, discuss the challenges that people face, and help folks understand what the difference is between Swagger and OpenAPI, and why they should be moving forward, and not staying in the past. This recurring session will start out exploring the divide and misconception that exists, and then evolve to be more formal about what enterprise organizations are needing to migrate: History - Quick recap of how we got here, including the difference between Swagger and OpenAPI. Differences - What are the key differences between Swagger 2.0 and OpenAPI 3.0.  Services - Look at how API services providers are using each of the specifications. Tooling - Understand the diff between tooling in both areas, understanding where deficiencies are. Storytelling - How can we tell more stories about OpenAPI that help people understand the difference. The goal here is to develop some basic curriculum that helps teams make the switch from Swagger to OpenAPI. Part of this will be to understand how to help get the word out about the difference and why it matters that we move forward. There is a number of misconceptions that exist the prevent folks from moving forward, and I am looking to help clear things up, get people focusing on the future of the specification, and shift the conversation to services and tooling around OpenAPI 3.0. This is just one of a handful of office hours I am looking to hold to facilitate discussions about OpenAPI. I am trying to help increase the awareness and demand for OpenAPI, and help push the community forward. If you have any questions about these office hours, feel...[Read More]


API Evangelist

The Quickest Way to Partner with Postman Is Through the Network

21 Jul 2020

One of the areas I am working on defining at Postman is how we partner with API providers, and API service providers. We are doing a lot of partnering right now, but we do not have a formal program for how we engage with our partners. Over the last couple of months I have been working to identify who all of our partners are, and define the common ways we partner with these various companies, non-profit organizations, institutions, and government agencies. I have a lot of people reaching out about partnering, and there are a lot of interesting APIs, services, and tooling providers I am looking to partner with, so we will need to get a little more formal about things if we are going to take things to the next level. One of the most obvious ways I can encourage folks to partner with Postman is to publish a collection for their API to the Postman public API network. Once Postman formalizes its partner strategy, this will become the lowest tier of partnership for the platform and community, providing a self-service way to engage with us (pssst! you don't have to wait). If you aren’t familiar, the Postman network is a public directory of APIs. To join all you have to do is click n the dropdown menu for each of your API collections, and choose to publish as docs.  As part of the process you are given the option to publish as part of the Postman API network—making your collection available on the web, and within the Postman desktop client. There are a bunch of settings as part of publishing documentation using Postman, and the collection discovery portion of the settings will allow you to control how things are published (or not). Once you hit publish the documentation and run in Postman button for your collection will show up under your user or team page, which is something you can repeat over and...[Read More]


API Evangelist

Postman Runtime Integrations

21 Jul 2020

I am working my way through all of the partner work I have on my workbench, and there is no better way to work through it than to write it out as blog posts here on API Evangelist. I just talked about how the easiest way to partner with Postman is by adding your collections to the API network. This is no guarantee of partnership, because Postman doesn’t have a formal partner program yet, but it is a quick way to get on the Postman community radar, and if your API and collection is interesting enough, we are likely to want to showcase more in other storytelling. Adding your collection to the Postman network is self-service and easy to do, you don’t need to talk with Postman to do it, but there is also another way in which you can partner with Postman that is also self-service, and will also get our attention. You can bake collections into your platform, which we like to call “runtime integrations”, because API service providers are integrating the Postman runtime into their services, and adopting the Postman collection schema as a common way to define API requests and workflows on their platform. An example of a Postman runtime integration can be found with API monitoring provider APIMetrics, who allows their customers to import a Postman collection and fire up industrial grade API monitoring at scale. Postman does monitoring, but it makes sense to embrace other service providers who offer competing or more comprehensive services, and a Postman collection is the perfect unit of currency to define this relationship. APIMetrics benefits from the over 11 million users of Postman, and Postman benefits because our customers can scale the services they use with Postman, and with all of our partners. Beyond APIMetrics, here are a handful of other service providers who have baked the Postman collection into their platforms. API Fortress (Testing / Monitoring) Assertible (Testing) AWS API Gateway (Deployment) Katalon...[Read More]


API Evangelist

What are People Doing with Swagger and OpenAPI?

20 Jul 2020

I recently harvested all of the open source tooling that is being built on the OpenAPI and Swagger specifications from GitHub. I am looking to better understand what people are doing with the specification, and parsing the words people use to describe their open source project is a good way for me to quickly pull together a list of what matters. If people are building a tool to solve a problem, and publish that on GitHub, it is a good sign that it is an itch needing scratching--here is the tag cloud from this list of what people are doing with both Swagger and OpenAPI. Semantically they all don’t jive, but it does paint an interesting picture of what is happening in the OpenAPI community. I am going to be working on this list to establish a more solid reference for the OpenAPI community. I am looking to profile all of these tools as part of the OAI demand generation work I am doing, but I am also interested in continuing to map the API lifecycle and keep mapping how open source OpenAPI tooling fits into the picture. We have built up a lot of momentum over the years, but this landscape is still pretty fractured and disorganized, making it difficult to navigate—I am looking to change that.[Read More]


API Evangelist

The OpenAPI Demand Generation Office Hours Last Friday

20 Jul 2020

I conducted the first OAI Demand Generation Public Office Hours last Friday. On behalf of the OAI I am looking to generate more awareness and demand around the specification, helping bring together members and non-members in the community to tell more stories about what is happening around the specification. I pitched the idea as part of the OAI marketing meeting, and didn’t want to waste any time in scheduling a meeting and getting the conversation going. We had a pretty small turnout for the first one, resulting me just talking about what I am already working on for over a half hour. However, we now have over 20 people added to the invite for the recurring meeting every Friday at 8:00 AM Pacific Time. Here are a few ways you can catch up on what is going on, and get involved: Head Over to GitHub - We are managing this effort out in the open on GitHub, using the README as a home page, and issues to help track ideas and projects that are moving forward. View Last Weeks Video - I am recording each session and publishing to YouTube for those who can’t make it. This one isn’t the highest quality, but I will get better at doing these in the future. Join the Conversation - Go ahead and email [email protected] if you’d like to be added to the Google Calendar invite for the OAI DemandGen Public Office Hours, and get the meeting in your calendar. We are looking to gather ideas from across the community about how we can build awareness of the OpenAPI specification, and increase more demand for the services and tooling that is built on top of it. I am aggregating ideas via the issue for the projects GitHub repository, and moving forward projects as I have time. If there is an idea you have, or an existing idea you have time to help move forward please jump in. This...[Read More]


API Evangelist

OpenAPI is the HTTP Binding in AsyncAPI

20 Jul 2020

I like researching and thinking more about each of the 13 AsyncAPI protocol bindings. It paints a picture of the past, present, and future of APIs for me. Leveraging AsyncAPI to define your event and message driven APIs is the future of API development, but one of the things I really, really, really, love about AsyncAPI as a specification is that the definition for the HTTP binding is just OpenAPI. Similar to how OpenAPI and AsyncAPI have baked in JSON Schema, AsyncAPI has baked in OpenAPI. In my opinion, this is how API specifications should work. There shouldn’t be one specification to rule them all, we let API specs compete on usefulness and the tooling that is built on top, and build on top of the specifications that already exist, preventing us from reinventing the wheel.  This kind of extensibility and reuse is what APIs are all about. This isn’t a question of OpenAPI vs. AsyncAPI, it is a question of AsyncAPI and OpenAPI. I know there is a lot of investment going into thinking about OpenAPI overlays for the next version, but as we have these thoughts I want to make sure this type of reuse gets considered. I am thinking very deeply about OpenAPI again, but I also find myself thinking very deeply about a number of API, data, and other operational level API specifications, and how they all work in concert. I am also thinking about where we need potentially new specifications, industry level specifications, and trying to find the bandwidth to continue talking about the future of APIs.json providing an index for all of API operations. OpenAPI, AsyncAPI, JSON Schema, and Postman collections have come a long way over the years, and I feel pretty poised to radically move forward how the API factory floor operates within the enterprise. I learned a lot about the technology, business, and politics of APIs by participating in the evolution of API specs from 2010 through...[Read More]


API Evangelist

What Are Some Resources For Understanding the World of Event-Driven APIs?

16 Jul 2020

I have been asked by more than 10 people in the last couple of weeks for more information for helping them make sense of the whole event-driven API landscape. I have all kinds of links available, and various organizations, tools, and other building blocks identified, but if I haven't told any stories on a subject, I won't have more refined information to share. To help seed my research and the resulting storytelling around the event-driven landscape. Here is what I have so far to help me understand what is going on, but also hopefully help others do their own research while I am developing my own understnading.  Protocols  HTTP - Keeping things in the realm of HTTP for developers.  HTTP/2 - Opening up bi-directional, multi-threaded events.  WebSockets - Leverage TCP for bi-directional pub/sub.  TCP - Leverage other TCP based protocols for events. Patterns WebHooks - Using fat or skinny payloods via HTTP push. REST Hooks - Defining links called when request is made. Pub/Sub - Adopting a publish & subscribe pattern. Standards AsyncAPI - Open source tools to easily build and maintain your event-driven architecture. Websub (formerly PubSubHubbub) - WebSub provides a common mechanism for communication between publishers of any kind of Web content and their subscribers, based on HTTP web hooks. Cloudevents - A specification for describing event data in a common way Server-Sent Events - Server-Sent Events (SSE) is a server push technology enabling a client to receive automatic updates from a server via HTTP connection. Performance One Direction - Pushing events in a single direction. Bi-Directional - Allow for bi-directional streams. Multi-Threaded - Opening up multiple threads at at time. Key Concepts Event Driven Event Sourcing Command Query Responsibility Segregation (CQRS) Event Storming Domain-Driven Design Complex Event Processing Top Links Spotify’s Event Delivery – Life in the Cloud (engineering.atspotify.com) Event-Driven Architecture (herbertograca.com) 5 Protocols For Event-Driven API Architectures (nordicapis.com) Replicating the Success of REST in Event-Driven Architecture (asyncapi.com) SOA vs. EDA: Is...[Read More]


API Evangelist

Demand Generation for the OpenAPI Specification

14 Jul 2020

I am making my rounds with folks in the API community talking about the next generation of the OpenAPI specification, getting people to move beyond Swagger 2.0, tooling and service providers to adopt more of the spec, and generate more demand for the specification and the work going on around it. Demand generation is such a business term to describe what I envision, but it is a word that people in the sector get, and neatly sums up what we need to do, so to hell with it. The OpenAPI spec has continued to evolve and grow, but things have clearly plateaued when it comes to the narrative coming out of the OAI, and from people doing interesting things with the specification in the API space. There is lots of activity, but there isn’t a clear overarching narrative about what is OpenAPI, why OpenAPI, and the tooling and service enablement that is occurring around it. I am looking to change this, gather ideas, turn up the volume, and get more people working with OpenAPI 3.1, and investing in the future of the spec. To help drive the demand generation discussion around OpenAPI I am going to be holding a recurring weekly demand generation discussion right after the regular OAI marketing meeting—here are the details if you want to join in the conversation. OpenAPI Demand Generation weekly at 11:00 AM Pacific Time on Google Meet - Let me know if you want a calendar invite to join in each week. While the meeting is associated with the OAI you do not have to be a member to participate. We are looking to gather ideas from the community about what we should be doing to generate more demand for the OpenAPI specification. I have been gathering ideas from one on one discussions with folks, so if you have any ideas and won’t be able to join in, feel free to email me or schedule some time to talk. We...[Read More]


API Evangelist

I Started API Evangelist 10 Years Ago

13 Jul 2020

I started planning API Evangelist in July of 2010 after I saw what was happening with APIs being used in the cloud, and powering mobile applications. By September I had a plan in place, and I figured out a name, bought a domain, and had established my approach to researching what was going on with web APIs. Ten years later I am still doing the work, and even though I’ve managed to burn out a couple of times, have had life get I’m the way, and more recently joined Postman as their Chief Evangelist, I am still beating the drum after all these years. I have learned a lot over the last decade. I don’t see APIs as good, nor bad, nor neutral anymore—they are as good or bad as whoever is wielding them, which with the lax security and ethics of most companies, it isn't always the API provider inflicting the most damage to the ecosystem. APIs leave me very concerned most days. I am not very keen on building and owning production APIs in the current online world, but I am happy to stay in tune with how the machine works, help evangelize for some ethics and sanity in how we use them, and hopefully be somewhat of a voice of reason in the space, even if I am still doing a significant amount of selling of the concept, and perpetuating of the myths.  The Only Thing That Has Changed Is That There Are More APIs There really hasn’t been any seismic shifts in the API landscape during my 10 years of studying what is going on. 80% of what occurs across the API lifecycle was going on in 2010. There are just more people doing it. Sure, there are a few new tricks and tools, but for the most part the APIs in 2020 are just like they were in 2010, it is just more mainstream companies doing them now, as well...[Read More]


API Evangelist

I Am Speaking About Powering the API Lifecycle with Collections & Environments Tomorrow at @APIdaysGlobal INTERFACE

29 Jun 2020

I am speaking tomorrow at 1PM Pacific time about using Postman collections and environments to define and power the API lifecycle at apidays INTERFACE. I am stoked that I get to have a dream job where I get paid to push forward ideas at this level, and wanted to share some of the ways I am using OpenAPI in conjunction with Postman collections and environments to define then execute across the API lifecycle for a variety of APIs. My talk is going to walk through the relationship between an OpenAPI and collections, but also begin pushing forward the notion of what collections are for, while also demonstrating that environments can be used for much more than just a place to put your API tokens and keys. Most developers know that you can use a Postman collection to store the details of an API you want to make requests to, helping you keep track of the all the details of each request and response. Developers have tons of these collections laying around, sometimes organized by personal and team workspaces. Developers are also using Postman environments to abstract away keys, tokens, and other key / values pairs that can be used across one or many collections. What most developers do not know is that you can use collections and environments to also deploy and manage your API across multiple stops along the API lifecycle, while also using them to measure and govern what is going with each API as it moves forward across a standardized API life cycle. My talk at APIdays INTERFACE is focused on this evolution in how Postman collections and environments can be applied to not just defining APIs, but also defining the API lifecycle. API Lifecycle Foundation To help ground each API I am developing I establish a strong foundation for moving each API forward, providing me with a layer I can use for delivering every other stop along the API lifecycle, consistently...[Read More]


API Evangelist

API Examples, Schema, Mocks, Static, Synthetic, Dynamic, Data, Functions, Frameworks, Gateway, Deployment, Documentation, and Client

24 Jun 2020

My head is swirling from a flurry of exciting meetings around what different Postman features are being worked on currently. I can’t speak directly on the features until they are released, but I am keen on pushing forward my understanding of the stops along the API lifecycle being served so that I can be articulate in meetings, while also helping light the fire under my readers imagination about what is possible with APIs. Today my head is moving very rapidly across the types of APIs I am producing or seeing produced, as well as the variety of approaches employed to bring these APIs to life—spanning from simple mocking of an API to full blow deployment of APIs at scale across multiple platforms, frameworks, and languages. I am thinking the overlap between examples I used in my APIs, how I mock with these examples, then evolve them into more static, synthetic, and dynamic mock implementations, or even possibly how these APIs then become real world production deployments. Currently you can mock your APIs with a variety of services, including Postman. I have also played around with a variety of ways to deploy APIs from an OpenAPI using Postman. I am looking for ways to help better quantify, visualize, and understand the different types of data we are making available via APIs, how those APIs are defined, hardened, and scaled, as well as documented and immediately accessible via a client like Postman.  I do not have the first clue in how to map this out as a single visualization or coherent narrative, but that won’t stop me from trying. Here are the dimensions I am working within, trying to define some sort of Venn diagram regarding how they work in concert. I can’t quite see it all yet, but this post is designed to help me bring it more into focus. I am trying to put these in order of need, but it is very difficult when they...[Read More]


API Evangelist

The Stops Along a Multi-Protocol API Lifecycle

12 Jun 2020

I spent the last week looking through open source tooling built around leading API specifications. If you are tuned into the RSS or Twitter feed from this blog you probably saw the exhaust from my research. People who don’t understand what API Evangelist is about often see these as listicle posts, and are confused by my erratic scheduling and release of these posts. If you understand that API Evangelist isn’t a tech blog in the normal sense, and that it is my professional API workbench, then you understand I am often times working towards some sort of research goal with each post. Well, this post is the next step in that research, taking me 12 separate research sprints to look through the API specification layer of our industry.  I am very interested in the top open source tools developed on top of these API specifications. However, I am also very interested in understanding how each of these tools contribute value to different stops along the API life cycle. These are the essential building blocks I identify to help me understand what people on the ground within organizations are needing when it comes to delivering APIs. Resulting in a pretty interesting list of capabilities, which are ordered based upon the frequency they are mentioned across all to the tooling for each of these dimensions. The results of this research is all pulled from GitHub, so I recognize it is an incomplete snapshot, but I still see it as the most representative source we have from across the API industry of how people are investing across the API life cycle.  Postman (See Open Source Tools) Collections, Testing, Data, Repos, Run,  CRUD, CLI , Client, Database. Requests, Automation., Framework, Learning, Load, Generate, Integration, Files, Send, Authentication, Scripts, Documentation, Runner , Import, Export, Local , Operations,  Search, Routes, Users, Clone, Design, Examples, Chain, Parse, Template, Mock, Environments , Training, Converter, Browser, Network, Visual OpenAPI (See Open Source Tools) Generate, CLI ,...[Read More]


API Evangelist

The Open Source Community Tooling Built on Thrift

11 Jun 2020

Continuing my journey through all of the leading API specifications I pulled the top open source projects that I could find via via the GitHub API. Pulling the cream off the top of what is being built, allowing me to loosely organize them by stop along the API life cycle. Resulting in an interesting mix of open source tools in a variety of languages, and platforms. Framework finagle - (forks: 1352) (stars: 7638) (watchers: 7638) - a fault tolerant, protocol-agnostic rpc system fbthrift - (forks: 475) (stars: 1931) (watchers: 1931) - facebook's branch of apache thrift, including a new c++ server. zys - (forks: 278) (stars: 813) (watchers: 813) - high performance service framework based on yaf or swoole spring cloud microservice - (forks: 236) (stars: 364) (watchers: 364) - spring-cloud-microservice-examples hprose - (forks: 34) (stars: 326) (watchers: 326) - hprose is short for high performance remote object service engine. it's a serialize and rpc library, the serialize library of hprose is faster, smaller and more powerful than msgpack, the rpc library is faster, easier and more powerful than thrift. workerman thrift - (forks: 115) (stars: 265) (watchers: 265) - thrift rpc for php based on workerman. hibari - (forks: 24) (stars: 248) (watchers: 248) - hibari is a production-ready, distributed, ordered key-value, big data store. hibari uses chain replication for strong consistency, high-availability, and durability. hibari has excellent performance especially for read and large value operations. gunicorn_thrift - (forks: 75) (stars: 190) (watchers: 190) - thrift app and worker for gunicorn! elixir thrift - (forks: 31) (stars: 168) (watchers: 168) - a pure elixir thrift implementation luxun - (forks: 35) (stars: 137) (watchers: 137) - a high-throughput, persistent, distributed, publish-subscribe messaging system based on memory mapped file and thrift rpc thrift rpc server - (forks: 36) (stars: 115) (watchers: 115) - thrift rpc server based on swoole dapeng soa - (forks: 30) (stars: 83) (watchers: 83) - a lightweight, high performance micro-service framework disruptor_thrift_server - (forks: 27) (stars: 66) (watchers: 66) - lmax disruptor backed thrift server...[Read More]


API Evangelist

The Open Source Community Tooling Built on RAML

11 Jun 2020

I have made my way through the open source community around Postman, OpenAPI, Swagger, AsyncAPI, JSON Schema, GraphQL, gRPC, Protocol Buffers, and Avro. Next up is RAML. Looking at the open source tooling built around the API specification, providing another look at how enterprise organizations are defining their APIs. Here is the current listing of open source tools built on to of RAML, loosely broken down by the areas of API operations that they serve. Specification raml spec - (forks: 815) (stars: 3610) (watchers: 3610) - raml specification Code Generation autorest - (forks: 545) (stars: 2861) (watchers: 2861) - openapi (f.k.a swagger) specification code generator. supports c#, powershell, go, java, node.js, typescript, python, ruby osprey - (forks: 71) (stars: 425) (watchers: 425) - generate node.js api middleware from a raml definition guardrail - (forks: 83) (stars: 341) (watchers: 341) - principled code generation from openapi specifications raml client generator - (forks: 25) (stars: 119) (watchers: 119) - template-driven generator of clients for apis described by a raml spec raml_ruby - (forks: 27) (stars: 96) (watchers: 96) - raml ruby nsxramlclient - (forks: 28) (stars: 41) (watchers: 41) - a pseudo dynamic client in python that takes the raml file as input, and composes the api call needed raml java client generato - (forks: 31) (stars: 25) (watchers: 25) - raml java client generator raml javascript generator - (forks: 17) (stars: 28) (watchers: 28) - generate a javascript api client from raml Deployment light 4j - (forks: 468) (stars: 2789) (watchers: 2789) - a fast, lightweight and more productive microservices framework ramses - (forks: 32) (stars: 305) (watchers: 305) - raml + elasticsearch / postgres / mongodb / your data store™ + pyramid = restful api proteus - (forks: 14) (stars: 163) (watchers: 163) - lean, mean, and incredibly fast jvm framework for web and microservice development. spring rest ecommerce - (forks: 84) (stars: 119) (watchers: 119) - java spring boot - ecommerce rest api go raml - (forks: 33) (stars: 125) (watchers: 125) - raml 1.0 implementation gemini - (forks: 17)...[Read More]


API Evangelist

The Open Source Community Tooling Built on Protocol Buffers

11 Jun 2020

Moving on in my API specification research I am continuing beyond just gRPC and looking at how Protocol Buffers are used across the space. GitHub provides a pretty good way to pull a snapshot of the community around Protocol Buffers, by measuring the engagement with open source tooling being built on top of the specification. Here are the top open source tools I pulled from this round of research into Protocol Buffers, organized by what they deliver. Specification protobuf - (forks: 11358) (stars: 42046) (watchers: 42046) - protocol buffers - google's data interchange format Serialization flatbuffers - (forks: 2251) (stars: 14468) (watchers: 14468) - flatbuffers: memory efficient serialization library protostuff - (forks: 248) (stars: 1419) (watchers: 1419) - java serialization library, proto compiler, code generator openrtb - (forks: 155) (stars: 353) (watchers: 353) - openrtb model for java and other languages via protobuf; helper openrtb libraries for java including json serialization Language Libraries protobuf - (forks: 1260) (stars: 6714) (watchers: 6714) - go support for google's protocol buffers protobuf.js - (forks: 1047) (stars: 6730) (watchers: 6730) - protocol buffers for javascript (& typescript). protobuf net - (forks: 852) (stars: 2939) (watchers: 2939) - protocol buffers library for idiomatic .net protoactor go - (forks: 339) (stars: 3192) (watchers: 3192) - proto actor - ultra fast distributed actors for go, c# and java/kotlin rust protobuf - (forks: 214) (stars: 1290) (watchers: 1290) - rust implementation of google protocol buffers prost - (forks: 132) (stars: 1061) (watchers: 1061) - prost! a protocol buffers implementation for the rust language php protobuf - (forks: 264) (stars: 861) (watchers: 861) - php protobuf - google's protocol buffers for php protobuf swift - (forks: 141) (stars: 913) (watchers: 913) - google protocolbuffers for apple swift lua protobuf - (forks: 202) (stars: 800) (watchers: 800) - a lua module to work with google protobuf brpc java - (forks: 166) (stars: 527) (watchers: 527) - java implementation for baidu rpc, multi-protocol & high performance rpc. grpclib - (forks: 49) (stars: 525) (watchers: 525) - pure-python grpc implementation for asyncio...[Read More]


API Evangelist

The Open Source Community Tooling Built on JSON Schema

11 Jun 2020

I am picking up my research into the open source tooling that is built around the common API specifications, and after looking at Postman collections, OpenAPI, Swagger, GraphQL, and gRPC, I wanted to look at JSON Schema. OpenAPI, AsyncAPI, and others use JSON Schema, and the ways in which JSON is used applies acros sthe API lifecycle. Here is the cream off the top of the open source tooling that I found being built on top of JSON Schema--providing another interesting dimension of what is happening. Normalization normalizr - (forks: 774) (stars: 19032) (watchers: 19032) - normalizes nested json according to a schema Forms react jsonschema form - (forks: 1365) (stars: 8497) (watchers: 8497) - a react component for building web forms from json schema. angular schema form - (forks: 662) (stars: 2422) (watchers: 2422) - generate forms from a json schema, with angularjs! jsonform - (forks: 456) (stars: 2025) (watchers: 2025) - build forms from json schema. easily template-able. compatible with bootstrap 3 out of the box. alpaca - (forks: 360) (stars: 1122) (watchers: 1122) - alpaca provides the easiest way to generate interactive html5 forms for web and mobile applications. it uses json schema and simple handlebars templates to generate great looking, dynamic user interfaces on top of twitter bootstrap, jquery ui, jquery mobile and html5. ncform - (forks: 110) (stars: 853) (watchers: 853) - 🍻 ncform, a very nice configuration generation way to develop forms ( vue, json-schema, form, generator ) react form generator - (forks: 45) (stars: 607) (watchers: 607) - generate, validate, and parse react forms using mongoose-inspired json schemas json forms - (forks: 154) (stars: 494) (watchers: 494) - json schema to html form generator, supporting dynamic subschemas (on the fly resolution). extensible and customizable library with zero dependencies. bootstrap add-ons provided ngx schema form - (forks: 153) (stars: 398) (watchers: 398) - html form generation based on json schema angular2 json schema form - (forks: 189) (stars: 282) (watchers: 282) - angular 2 json schema form builder native -...[Read More]


API Evangelist

The Open Source Community Tooling Built on Avro

11 Jun 2020

Continuing my march through the event-driven and message-driven world of API specifications I am workking my way through the open source tooling that is built on the Avro specification.  I am looking to better understand how the data serialization system is being put to work, and the relationship with the other layers of the API specification conversation. Here is the top tooling I'm tracking on when it comes to Avro, organized by group. Specification avro - (forks: 1066) (stars: 1594) (watchers: 1594) - apache avro is a data serialization system. Registries schema registry - (forks: 736) (stars: 1234) (watchers: 1234) - confluent schema registry for kafka schema registry ui - (forks: 88) (stars: 321) (watchers: 321) - web tool for avro schema registry | schemer - (forks: 3) (stars: 90) (watchers: 90) - schema registry for csv, tsv, json, avro and parquet schema. supports schema inference and graphql api. Queries rq - (forks: 45) (stars: 1553) (watchers: 1553) - record query - a tool for doing record analysis and transformation Education examples - (forks: 458) (stars: 670) (watchers: 670) - apache kafka and confluent platform examples and demos kafka storm starter - (forks: 335) (stars: 726) (watchers: 726) - code examples that show to integrate apache kafka 0.8+ with apache storm 0.9+ and apache spark streaming 1.1+, while using apache avro as the data serialization format. avro hadoop starter - (forks: 86) (stars: 111) (watchers: 111) - example mapreduce jobs in java, hive, pig, and hadoop streaming that work on avro data. Avro2TF - (forks: 19) (stars: 118) (watchers: 118) - avro2tf is designed to fill the gap of making users' training data ready to be consumed by deep learning training frameworks. Serialization avsc - (forks: 98) (stars: 844) (watchers: 844) - avro for javascript :zap: avro4s - (forks: 178) (stars: 536) (watchers: 536) - avro schema generation and serialization / deserialization for scala fastavro - (forks: 115) (stars: 362) (watchers: 362) - fast avro for python gogen avro - (forks: 66) (stars: 191) (watchers: 191) - generate...[Read More]


API Evangelist

The Open Source Community Tooling Built on AsyncAPI

11 Jun 2020

Continuing my dive into the open source tooling around leading API specification I am looking at AsyncAPI. The event-driven and message-driven API specification is sitll fairly new so the community isn't nearly the size of OpenAPI or Swagger, but there is plenty of insights to mine from what is being built. Here is the list I have compiled so far when it comes to AsyncAPI, something I've grouped, but will keep adding to and evolving as I continue this work. Specification asyncapi - (forks: 77) (stars: 1139) (watchers: 1139) - the asyncapi specification allows you to create machine-readable definitions of your asynchronous apis. Documentation widdershins - (forks: 208) (stars: 665) (watchers: 665) - openapi / swagger, asyncapi & semoasa definitions to slate / shins compatible markdown generator - (forks: 54) (stars: 113) (watchers: 113) - use your asyncapi definition to generate literally anything. markdown documentation, node.js code, html documentation, anything! api2html - (forks: 18) (stars: 93) (watchers: 93) - a cli tool to transform swagger/openapi/asyncapi docs to beautiful html pages via shins/widdershins. github action - (forks: 0) (stars: 24) (watchers: 24) - github action to deploy your api documentation on bump docgen - (forks: 11) (stars: 17) (watchers: 17) - asyncapi documentation generator. deprecated in favour of swagger4kafka - (forks: 4) (stars: 17) (watchers: 17) - automated documentation for kafka consumers built with spring (with @kafkalistener) saunter - (forks: 7) (stars: 15) (watchers: 15) - saunter is an asyncapi documentation generator for dotnet. scribano - (forks: 0) (stars: 5) (watchers: 5) - automatically build asyncapi documentation for your rabbitmq messages Definitions slack api specs - (forks: 36) (stars: 122) (watchers: 122) - open api specifications for platform products by slack Filters openapi filter - (forks: 14) (stars: 32) (watchers: 32) - filter internal paths, operations, parameters, schemas etc from openapi/swagger/asyncapi definitions Code Generation asyncapi react - (forks: 13) (stars: 23) (watchers: 23) - asyncapi react component node codegen - (forks: 5) (stars: 14) (watchers: 14) - an asyncapi codegen for node.js apicurio data models - (forks: 6) (stars: 11)...[Read More]


API Evangelist

The Open Source Community Tooling Built on API Blueprint

11 Jun 2020

Last on my list of API specifications to profile is API Blueprint. Once, one of the more promising API specifications leading the API design first charge, post acquisition there isn't a whole lot of forward motion. However, API Blueprint still provides a pretty compelling view of the landscape, and is worth tuning into to understand what is happening. Here are the API Blueprint open source tools I harvested from the GitHub API and organized by stop along the API life cycle they are serving. Specification api blueprint - (forks: 2095) (stars: 7969) (watchers: 7969) - api blueprint Generators aglio - (forks: 489) (stars: 4480) (watchers: 4480) - an api blueprint renderer with theme support that outputs static html laravel blueprint docs - (forks: 27) (stars: 204) (watchers: 204) - api blueprint renderer for laravel, customizable via blade templates Toolchains snowboard - (forks: 100) (stars: 641) (watchers: 641) - api blueprint toolkit Converters api spec converter - (forks: 91) (stars: 616) (watchers: 616) - convert api descriptions between popular formats such as openapi(fka swagger), raml, api blueprint, wadl, etc. apiary2postman - (forks: 25) (stars: 188) (watchers: 188) - tool for generating a postman collection from blueprint api markup or the apiary api blueman - (forks: 18) (stars: 143) (watchers: 143) - convert a generated api blueprint json file into a postman collection swagger2blueprint - (forks: 9) (stars: 98) (watchers: 98) - convert swagger api descriptions into api blueprint pmtoapib - (forks: 1) (stars: 33) (watchers: 33) - tool to convert postman collection exports to api blueprint documentation postman2apiary - (forks: 10) (stars: 22) (watchers: 22) - tool for generating blueprint api markup or the apiary api from a postman collection. apib2json - (forks: 10) (stars: 14) (watchers: 14) - a command-line utility for convert api blueprint to json schema apib2json - (forks: 10) (stars: 14) (watchers: 14) - a command-line utility for convert api blueprint to json schema Mocking api mock - (forks: 63) (stars: 492) (watchers: 492) - creates a mock server based on an api blueprint drakov -...[Read More]


API Evangelist

The Open Source Community Tooling Built on gRPC

09 Jun 2020

I am getting time to map out the diverse API toolbox landscape I see unfolding lately. I am aggregating the most used open source projects across the leading API specifications in use. While gRPC is more of a style or pattern than it is a specification--it is a fast growing standard. I'll be doing a separate analytics of Protocol Buffers, but I wanted to look at the cream on top of what is being build within the gRPC community. Revealizing almost a hundred open source tools loosely organized by what they deliver as part of the API lifecycle. Specification grpc - (forks: 6625) (stars: 26420) (watchers: 26420) - the c based grpc (c++, python, ruby, objective-c, php, c#) Implementations grpc - (forks: 6625) (stars: 26420) (watchers: 26420) - the c based grpc (c++, python, ruby, objective-c, php, c#) rpcx - (forks: 772) (stars: 4675) (watchers: 4675) - a zero cost, faster multi-language bidirectional microservices framework in go, like alibaba dubbo, but with more features, scale easily. try it. test it. if you feel it's better, use it! 𝐉𝐚𝐯𝐚有𝐝𝐮𝐛𝐛𝐨, 𝐆𝐨𝐥𝐚𝐧𝐠有𝐫𝐩𝐜𝐱! surging - (forks: 860) (stars: 2875) (watchers: 2875) - surging is a micro-service engine that provides a lightweight, high-performance, modular rpc request pipeline. the service engine supports http, tcp, ws, grpc, mqtt, udp, and dns protocols. it uses zookeeper and consul as a registry, and integrates it. hash, random, polling, fair polling as a load balancing algorithm, built-in service governance to ensure reliable rpc communication, the engine contains diagnostic, link tracking for protocol and middleware calls, and integration skywalking distributed apm iris - (forks: 2035) (stars: 18281) (watchers: 18281) - The fastest community-driven web framework for go. grpc, automatic https with public domain, mvc, sessions, caching, versioning api, problem api, websocket, dependency injection and more. fully compatible with the standard library and 3rd-party middleware packages. | https://bit.ly/iriscandothat1 | https://bit.ly/iriscandothat3 | grpc web - (forks: 295) (stars: 2995) (watchers: 2995) - grpc web implementation for golang and typescript tonic - (forks: 167) (stars: 2166)...[Read More]


API Evangelist

The Open Source Community Tooling Built on GraphQL

09 Jun 2020

I have done several dives into the world of GraphQL. As part of some API specification work I am not getting another chance to look at what the open source community around GraphQL looks like. Along with other API specifications in our modern API toolbox, I am looking at how GraphQL is being leverage, and what the motivations are behind the open source tooling that has emerged. Resulting in the following list of the cream off the top of the open source tooling build on top of GraphQL, broken down by different stops along the API lifecycle. Formatting prettier - (forks: 2366) (stars: 36727) (watchers: 36727) - prettier is an opinionated code formatter. Server Code strapi - (forks: 3163) (stars: 25979) (watchers: 25979) - 🚀 open source node.js headless cms to easily build customisable apis parse server - (forks: 4325) (stars: 17541) (watchers: 17541) - api server module for node/express graphql js - (forks: 1553) (stars: 16196) (watchers: 16196) - a reference implementation of graphql for javascript graphql engine - (forks: 1428) (stars: 17060) (watchers: 17060) - blazing fast, instant realtime graphql apis on postgres with fine grained access control, also trigger webhooks on database events. apollo server - (forks: 1391) (stars: 9707) (watchers: 9707) - 🌍 graphql server for express, connect, hapi, koa and more graphql - (forks: 557) (stars: 6454) (watchers: 6454) - an implementation of graphql for go / golang api platform - (forks: 669) (stars: 5853) (watchers: 5853) - rest and graphql framework to build modern api-driven projects (server-side and client-side) graphene - (forks: 612) (stars: 5758) (watchers: 5758) - graphql framework for python graphql yoga - (forks: 366) (stars: 5763) (watchers: 5763) - 🧘 fully-featured graphql server with focus on easy setup, performance & great developer experience express graphql - (forks: 483) (stars: 5319) (watchers: 5319) - create a graphql http server with express. graphql ruby - (forks: 936) (stars: 4297) (watchers: 4297) - ruby implementation of graphql graphql java - (forks: 781) (stars: 4267) (watchers: 4267) - graphql java implementation graphql php -...[Read More]


API Evangelist

The Open Source Community Tooling Built on Swagger

08 Jun 2020

I am finally finding time to pick up some old work quantifying the open source that has risen up around API specifications. I just pulled all the GitHub repos when you search for "Postman" and "OpenAPI", and now I wanted to do "Swagger". I'm looking to evaluate the cream off the top of what is going on in each of these buckets, but also eventually evaluate the long tail of what is going on. I've been trying to understand the evolution of Swagger 2.0 to OpenAPI 3.0 from a tooling perspective for some time now--this is me getting a handle on what is happening. Here is the top repositories when you search for "Swagger" on GitHub, roughly broken down by the stops along the API lifecycle they are serving. Deployment fastapi - (forks: 942) (stars: 14208) (watchers: 14208) - fastapi framework, high performance, easy to learn, fast to code, ready for production connexion - (forks: 542) (stars: 3150) (watchers: 3150) - swagger/openapi first framework for python on top of flask with automatic endpoint validation & oauth2 support surging - (forks: 860) (stars: 2875) (watchers: 2875) - surging is a micro-service engine that provides a lightweight, high-performance, modular rpc request pipeline. the service engine supports http, tcp, ws, grpc, mqtt, udp, and dns protocols. it uses zookeeper and consul as a registry, and integrates it. hash, random, polling, fair polling as a load balancing algorithm, built-in service governance to ensure reliable rpc communication, the engine contains diagnostic, link tracking for protocol and middleware calls, and integration skywalking distributed apm light 4j - (forks: 468) (stars: 2789) (watchers: 2789) - a fast, lightweight and more productive microservices framework loopback next - (forks: 499) (stars: 2810) (watchers: 2810) - loopback makes it easy to build modern api applications that require complex integrations. swag - (forks: 386) (stars: 2668) (watchers: 2668) - automatically generate restful api documentation with swagger 2.0 for go. scalatra - (forks: 337) (stars: 2454) (watchers: 2454) - tiny scala high-performance, async web...[Read More]


API Evangelist

The Open Source Community Tooling Built on Postman

08 Jun 2020

I am finally finding time to pick up some old work quantifying the open source that has risen up around API specifications. I am pulling all of the open source tooling available on GitHub when you search for "Postman". A portion of this is open source by Postman, others are collections built by API providers helping developers on-board more quickly, but there is another set of tooling that builds on top of the concept of Postman collection as a specification. Providing an interesting look at what developers are wanting when it comes to integrating the Postman platform into their oeprations. I have a longer list of everything, but here is the cream off the top. Documentation postmanerator - (forks: 69) (stars: 470) (watchers: 470) - a http api documentation generator that use postman collections docgen - (forks: 52) (stars: 335) (watchers: 335) - transform your postman collection to html/markdown documentation docodile - (forks: 23) (stars: 54) (watchers: 54) - generate html api documentation from a postman collection docman - (forks: 18) (stars: 47) (watchers: 47) - a simple page to generate documentation from postman collections Postdown - (forks: 14) (stars: 36) (watchers: 36) - generate markdown api document from postman. postman2doc - (forks: 5) (stars: 25) (watchers: 25) - convert postman collection.json to markdown/html/docx. Educational All Things Postman - (forks: 86) (stars: 304) (watchers: 304) - a selection of examples using postman rest client Conversion apiary2postman - (forks: 25) (stars: 188) (watchers: 188) - tool for generating a postman collection from blueprint api markup or the apiary api API Flow - (forks: 19) (stars: 181) (watchers: 181) - universal data structure and converter for api formats (swagger, raml, paw, postman…) blueman - (forks: 18) (stars: 143) (watchers: 143) - convert a generated api blueprint json file into a postman collection api spec converter - (forks: 76) (stars: 108) (watchers: 108) - this package helps to convert between different api specifications (postman, swagger, raml, stoplight). swagger2 to postman - (forks: 46) (stars: 92) (watchers: 92) - converter for...[Read More]


API Evangelist

The Open Source Community Tooling Built on OpenAPI

08 Jun 2020

I am finally finding time to pick up some old work quantifying the open source that has risen up around API specifications. I am pulling all of the open source tooling available on GitHub when you search for "OpenAPI". I just published the same assessment of searching for "Postman", but since Postman's API builder is centered around OpenAPI, it makes sense to do the same for OpenAPI. I'm looking to develop a understanding with many of the tooling provider listed here, but I am also looking to understand what developers are needing when it comes to OpenAPI. I have gone through the cream off the top of the search for "OpenAPI" on GitHub and here is what I have come up with so far. Specifications OpenAPI Specification - (forks: 6456) (stars: 17676) (watchers: 17676) - the openapi specification repository Parser swagger parser - (forks: 96) (stars: 604) (watchers: 604) - swagger 2.0 and openapi 3.0 parser/validator kin openapi - (forks: 111) (stars: 503) (watchers: 503) - openapi 3.0 implementation for go (parsing, converting, validation, and more) oas kit - (forks: 84) (stars: 436) (watchers: 436) - convert swagger 2.0 definitions to openapi 3.0 and resolve/validate/lint openapi.tools - (forks: 114) (stars: 174) (watchers: 174) - a collection of editors, linters, parsers, code generators, documentation, testing Validator swagger parser - (forks: 96) (stars: 604) (watchers: 604) - swagger 2.0 and openapi 3.0 parser/validator kin openapi - (forks: 111) (stars: 503) (watchers: 503) - openapi 3.0 implementation for go (parsing, converting, validation, and more) oas kit - (forks: 84) (stars: 436) (watchers: 436) - convert swagger 2.0 definitions to openapi 3.0 and resolve/validate/lint openapi cop - (forks: 10) (stars: 325) (watchers: 325) - a proxy that validates responses and requests against an openapi document. express openapi validator - (forks: 51) (stars: 253) (watchers: 253) - 🦋 auto-validates api requests, responses, and securities using expressjs and an openapi 3.x specification openapi.tools - (forks: 114) (stars: 174) (watchers: 174) - a collection of editors, linters, parsers, code generators, documentation, testing Generators...[Read More]


API Evangelist

Setting Up API Broker Workspaces

08 Jun 2020

I had begun playing around with the concept of API brokers back in 2014, and it is something that is recurring and evolving in a handful of the conversations I am having in the Postman ecosystem lately. API brokering is the concept that instead of developers directly engaging with all of the public APIs they will ned for an application, that a professional API broker could discover, sign-up, setup applications, and aggregate documentation, client libraries, and other essential items for developers. So all an application developer has to do is fire up a workspace, and they have all the docs, code, keys, and other elements ready to go for them to just start building. Saving an organization time and money by outsourcing much of the tedious work involved with discovering APIs, on-boarding with them, and preparing to build an API, letting organizations focus on what they do best.   Most of my talk in the past has been conceptual around being an API broker, but now with Postman I can actually do it for realz. I can take the many different workspaces of API collections I have and use them to populate client specific workspaces. Meaning I can setup a workspace specifically for companies I know that want quick access to a variety of APIs--without the friction of on-boarding themselves. Here are the building blocks I’ve established for my own definition of the API broker / client relationship.   User - I am on the business plan, so I add a new slot for each of my clients, paying for their team license as part of the overall value that I am delivering to them. They use this user account whenever they are engaging with the API I am maintaining for them. I can apply appropriate roles, and terminate access whenever the relationship ends.  Workspace - I setup a single workspace for my client, allowing them to access only the API, collections, environments, tests, and...[Read More]


API Evangelist

Writing and Working in a COVID-19 #BlackLivesMatter Uprising Storm

05 Jun 2020

Business is anything but usual these days. I have a lot of time on my hands when it comes to writing and working online, but the reality in the chair is anything but easy. When I sit down to tackle even the most basic of tasks I can usually make it through about 50% of the work before I feel drained, and left with a blank screen for a brain. In addition to COVID-19 and the #BlackLivesMatter uprising, we also lost the kid this month. Making for a swirling emotional mess of a reality that really isn’t conducive to doing much beyond just reading a book or watching a movie. Looking through my notebook there are numerous half, or even complete stories about APIs I could be publishing, but my blank screen of a brain can’t even properly edit them, let along grock and finish many of the API stories I was pushing forward. It is difficult for me on the best day to conjure up some storytelling about APIs here on the blog. With that said, it also can be useful to lose myself thinking about some technical topics if I can find ways to convince myself that they are meaningful in these times. Technology is no replacement for direct human action, but the forces we are up against are actively wielding API-driven technology against us, and pushing back on this has always been what API Evangelist is all about. It isn’t about just saying the Twitter API can be used for social justice, it is also about demonstrating to folks that the Twitter API is also being used to surveil and manipulate us. Pulling back the curtain on how all of this works is the cornerstone of what API Evangelist does, and I’m determined to find ways of doing this in service of the #BlackLivesMatter uprising. This is one of those “getting back on the horse” posts. Where I just practice using my...[Read More]


API Evangelist

The Building Blocks of API Sharing and Collaboration

05 Jun 2020

I am tasked with defining what sharing and collaboration means when it comes to API operations at work. I have never had a tool like Postman to help me define how we work as a team across an organization. Normally, I just do a lot of hand waving and say, “you do it like this”, and call it good. With Postman, I now have an opportunity to anchor what I am talking about using the current state of the Postman platform, as well as help shape the future by influencing the Postman road map.  To help me prepare for more coherent storytelling on the Postman blog, and as part of other conversations, I want to work my way through what the core features of Postman are when it comes to sharing and collaboration. There are many levels to how you can share and collaborate within Postman, which will have different impacts on the ground within enterprise organizations. To help me map Postman functionality to the real world of API operations, I wanted to break down the different level of sharing and collaboration that exists within Postman. Team Level The essential ingredient of API sharing and collaboration is a team. You just can’t effectively share and collaborate at the provider level without a team. You can share and collaborate in spontaneous ways amongst API provider stakeholders, as well as API consumer stakeholders, but with a well defined team of stakeholders you can take sharing and collaboration to new levels. Here are a couple of the core Postman features that facilitate sharing and collaboration across API operations. Create a Team - The act of creating a team in Postman, and upgrading your account to support the size and scope of your team is the first thing you can do to help lay a foundation that facilitates sharing and collaboration within a team, but also between teams. Invite to a Team - The process of inviting someone to...[Read More]


API Evangelist

What Layer Are You Used to API Complexity Being At?

22 May 2020

I’d say one of the most controversial aspects of the world of APIs involves the places where people are used to and prefer to deal with API complexity at. After you look at thousands of APIs you begin to better understand where people introduce complexity into the design of an API, and as more people become familiar with any single approach they are much more likely to stick with it over time, bake it into their APIs, and passionately believe it is the normal pattern that everyone else is and should be using. You can see what I am talking about at the heart of the microservices debate, where the API complexity is dealt with at the API level, or in the number of APIs you have—something many increasingly are finding to be unacceptable. Another way you can see the API complexity debate unfolding across the API space is within the graphQL, where the complexity is at the schema level, and believers truly think that this is where API complexity should live. I try to not be too prescriptive on where API complexity should lie because the reasons why you want to increase or decrease the scope and complexity of an API will vary widely depending on what you are delivering with the API, the organization where it is being produced, and who will be consuming it. First, What is API Complexity? I feel like it is important to set the stage with what is complex. To provide a complicated view of what complexity can be, the definition for the complexity is, “the state or quality of being intricate or complicated”, with the definition of complicated being, “consisting of many interconnecting parts or elements; intricate.”, and the definition of intricate being, “very complicated or detailed”. ;-)  Here are some of the questions that nag me as I think about API complexity. Is complexity in each individual API instance necessary? Is complexity in each individual API...[Read More]


API Evangelist

Where is the API Value?

08 May 2020

I had some thoughts bouncing around in my head the last couple days about where the value in this whole API game actually resides. When it comes to the types of APIs I am seeing be deployed, and where I see things head in the near future, I wanted to try and map out where the different moving parts of an API are, and assigning value to each component. At first I just wanted to think more deeply about how Claude Shannon the father of information theory would see (or not see) the value in APIs. In 1948 Claude Shanno wrote in his Mathematical Theory of Communication: The fundamental problem of communication is that of reproducing at one point either exactly or approximately a message selected at another point. Frequently the messages have meaning; that is they refer to or are correlated according to some system with certain physical or conceptual entities. These semantic aspects of communication are irrelevant to the engineering problem. The significant aspect is that the actual message is one selected from a set of possible messages. The system must be designed to operate for each possible selection, not just the one which will actually be chosen since this is unknown at the time of design. In 2020, I feel like the message is still the center of value, but I would disagree about the meaning of those messages being irrelevant, but that is another post. However I would say that other dimensions have emerged in the 70+ years since Shannon wrote his theory. I would argue that Shannon's view of the message still hold true in 2020, but I just think he couldn't have imagined the many ways in which protocols, connections, formats, channels, and the network, performance, and volume of messages would influence the purpose, meaning, and ultimately value of each message, and messages in bulk. This is my first draft at trying to map out the moving parts. It is...[Read More]


API Evangelist

API Spec-First Development

07 May 2020

I am fleshing out ideas from a couple of recent conversations around API life cycle religion and philosophy. We’ve made our way through several lofty ideologies around how you should or shouldn’t do APIs, and next up in the queue is API specification first, or API spec first development. I like the phrase. I like it a lot. However, I am afraid if we aren’t being precise in what we mean by it we might be sacrificing a more meaningful usage of it for delivering a certain class of API that is meant for reuse. This is another one of my pedantic API definition stories, but since it is meant to help me use my words better in these conversations I am having, and secondarily for a wider reading here on the blog, you are going to have to bear with me as I work through my feels about API spec first development (should there be any dashes in there?) To help guide me in my work, I am using my API reference implementation “Union Fashion” as a foundation for this narrative. I’ve been calling what I am doing with Union Fashion API-first, but honestly I’m just looking to build out the best reference implementation that I can showing how to do APIs thoughtfully—I am not trying be prescriptive about there being one way do APIs, or one phrase to describe it. It just doesn’t exist. However, I do like peeling back the layers on the onion until I cry. When it comes to Union Fashion I might be agreeable to calling what we are doing API spec first development, if we are using it in two possible ways. Let’s use the Union Fashion products API to help break things down and see if we can’t help flesh out what we mean by API spec first development. The Product API Began With Three Specifications When I first started development of the Union Fashion product API...[Read More]


API Evangelist

The Basics of Postman Role Based Access Control (RBAC)

05 May 2020

I am working up towards a loftier piece on the importance of RBAC to the API life cycle, and as part of my research I was going through all of the documentation postman has for roles and permission at the team, workspace, api, and collection levels. RBAC is one of those layers of the API discussion that touches on almost every other layer, making it an area you have to not just think about at the microscopic levels within workspaces, but also at the macro level thinking about organizational and team level impact. I’m feeling like I am going to need to flesh out several dimensions of what is RBAC here on the blog, as well as the other critical factors of what influences RBAC across operations. The Basic Building Blocks of Postman RBAC To get a handle on things I wanted to think deeply about the core building blocks of Postman RBAC, and consider the roles, as well as the objects in which access is being controlled, but also the downstream effects of how RBAC gets applied or not. When you browse the Postman Learning Center under roles and permissions you get the following breakdown: Team Role Admin: manage team members and team settings Billing: manage team plan and payments Developer: access team resources and workspaces Workspace Roles Admin: manage workspace details and members Collaborator: work on team resources in a workspace API Roles Editor: edit APIs directly Viewer: view, fork, and export APIs Collection Roles Editor: edit collections directly Viewer: view, fork, and export collections That represents nine individual roles defined by the API resources in which they are applied. Postman does a good job of breaking out the control each role has in each of the respective areas, but the overall effectiveness of RBAC will be determined by how solid of a strategy you have for defining and managing each of these areas—meaning you are going to to have a strategy in place,...[Read More]


API Evangelist

Learn by API

05 May 2020

I was playing around with my co-worker Sue Smith’s Learn by API project today, and found it to be a pretty powerful usage of Postman for not just teaching users about Postman, but also teach them about healthy practices when it comes to API design. The Learn by API Postman collection provides an interesting building block for development of other introductory API concepts, but also API design concepts in service of a formal API governance strategy across an organization. I recommend you just click on the Run in Postman button for the Learn by API to collection to better understand the potential, but I’d also like to break down what she did to help illustrate how it could be used as an API education and training blueprint. Learning Collection The Learn by API collection is a single request wrapped in a portable Postman collection, allowing anyone (with Postman installed) download into their desktop client and execute. Teaching anyone (developers or non-developers) about the fundamentals of Postman, API design, as well as how the web works in general. To begin learning, all you do is click send in Postman once you have imported the collection, and you’ll will be introduced to the next step. The collection introduces each user to how Postman makes requests, how APIs are designed by showing the mechanics of how the web is working behind our web and mobile applications. It also really shows how Postman is all about helping you understand APIs by peeling back the layers of HTTP requests and responses in a hands on way. Visualizer Experience Once you have clicked send you see the response body as JSON, however if you click on the Visualize tab. Here you are given an HTML view of the tutorial you have initiated. The collection helps you understand what you just set into motion by sending the request, fusing the tutorial with the response of the request you initiated. Immediately immersing you...[Read More]


API Evangelist

HHS and CMS Finalizes Rules to Provide Patients More Control of Their Health Data Using APIs

05 May 2020

I have had a pretty massive API story in my notebook for a couple of weeks now that I just didn’t have the emotional bandwidth to process, but eventually I’m finding the energy to think about APIs at this scope. The TL;DR is that the US Health & Human Services (HHS) finalized a historic rule to provide patients more control of their health care using APIs--from the HHS announcement: “ONC’s final rule establishes secure, standards-based application programming interface (API) requirements to support a patient’s access and control of their electronic health information. APIs are the foundation of smartphone applications (apps). As a result of this rule, patients will be able to securely and easily obtain and use their electronic health information from their provider’s medical record for free, using the smartphone app of their choice.” I wanted to understand what this means for healthcare APIs. I’ve gone down the Blue Button API rabbit hole several times before, and I have an intimate awareness of how much time is involved with just loading all the moving parts into your head. However, this is why I write on API Evangelist, to help me process big ideas like this through ongoing API storytelling, and whittle away at projects I may not have time for in waves. I finally made time to do a first dive into this monumental precedent in the US federal government directing healthcare providers to deploy APIs, loading it all up in my head so I can chew on for a bit. The CMS Interoperability and Patient Access Final Rule The technical meat of this can be found within the CMS interoperability and patient access final rule. Helping me better understand what is being asked of healthcare providers, and who the providers even are. At this point the rule sounds promising because of its scope, but really the devil is in the details--the CMS interoperability and patient access final rule document(s) provide:  Information and tools...[Read More]


API Evangelist

Blog Posts to Work Through My API Task List

05 May 2020

I would say today reflects the purpose of API Evangelist in my world. Helping me get through the work I have on the table, while expanding my awareness of what is going on in the world of APIs. Most people think my blog is for them, and it is, but first and foremost it is about me working through my ideas and projects. I haven’t been feeling like writing much during the current situation we find ourselves in, but this morning I was needing some help getting to some items on my task list that have been sitting a little to long. Resulting in three posts here on the blog, and me remember why I do this, which always helps me find renewed energy in my work. I have about 10 different items I was looking to accomplish today, but three of them made for pretty worthy stories that helped me better understand what is going on while also pushing me to articulate my ideas to other people. Here is the result of me clearing three items from my task list today: Learn by API - I was impressed by a new type of collection my co-worker at Postman came up with, making learning about APIs and Postman a hands-on experience. I am going to adopt her approach for my Union Fashion API reference project. The Basics of Postman Role Based Access Control (RBAC) - Refreshing my memory of what is possible with Postman RBAC, so that I can pull together a compelling story about how Postman RBAC benefits our enterprise customers. HHS and CMS Finalizes Rules to Provide Patients More Control of Their Health Data Using APIs - Digging deeper into HHS and CMS finalizing a rule for payment providers to deploy Blue Button compliant APIs to give patients more access to their developers. This process reflects how I like to work. It represents how I have managed to move my API research forward...[Read More]


API Evangelist

The Quickest Way To Make An Idea for an API Usable By Others

04 May 2020

I have used Postman in a handful of webinars and takes recently to demonstrate how you can quickly go from idea to a tangible usable API. My goal is to equip myself with a way to I can quickly demonstrate an API I have in my head to someone else in five minutes or less. This is a walkthrough of that process, hopefully showing you a quick way to be more effective in how you share and collaborate around APIs. Allowing anyone, even non-developers to make their abstract ideas a little more tangible and real for others. Oakland Restaurants JSON To demonstrate how you can quickly deploy an API using Postman I’ve compiled a list of some of the restaurants in Oakland (where I live) that are still open for take-out and delivery. To demonstrate what is possible I have added four restaurants to a JSON file, providing me with what I’d like to see for my API response. This JSON will become the response for me new API, providing a list of restaurants for Oakland. However, with an eye for the future I will be looking to create separate JSON responses for Berkeley and other surrounding cities, breaking up my API into more usable chunks. New API Request in Postman To launch my new restaurants API I am opening up Postman, creating a new request for the API I am wanting to share with others. Adding a path resource named restaurants with a city parameter with a value of Oakland, allowing me to break things up by city in the near future. Save Request as a Collection Before I can actually put my new imaginary API to work I will need to save the request as part of a collection. Helping provide me with a way to organize my API, but also begin to make it more tangible and executable as a Postman collection. Taking the first step towards making my API idea a...[Read More]


API Evangelist

Using Postman Workspaces and GitHub Repositories Together

01 May 2020

I find that it helps to have defined boundaries for your APIs. If you have the resources and interest I recommend studying subjects like domain driven design. Investment in properly defining the boundaries of your organization and lines of business is a very worthy endeavor—if you have the time. However, if you already have a lot on your plate, and are just looking for incremental changes that can help make your life easier when it comes to the API sprawl we’ve introduced into our worlds, I recommend just spending a few moments thinking about how you can better use Postman workspaces to dive and conquer your API landscape. I have begun using Postman workspaces in similar ways that I use GitHub repositories. The GitHub repository has long represented a unit of API value in my world, but with the introduction of GitHub two-way sync into Postman I now have a one for one matchup between workspace and repository when it comes to moving each API forward. For my API-first e-commerce reference implementation Union Fashion I am currently developing five separate APIs, which each have their own Postman workspace and GitHub repository pairing. Products - (Workspace) (Repo) (Docs) - Defining all of the products that Union Fashion offers. Orders - (Workspace) (Repo) (Docs) - Allows for the ordering of Union Fashion products online. Baskets - (Workspace) (Repo) (Docs) - Allows for the ordering of Union Fashion products online. Users - (Workspace) (Repo) (Docs) - Defines users who engage with the Union Fashion platform. Search - (Workspace) (Repo) (Docs) - Provides a universal search for products, orders, and users. Postman workspaces and GitHub repositories accomplish many overlapping concerns along the API life cycle, however I am finding that Postman workspaces are better suited for establishing a tighter team level definition of who should have access and voice in moving an API forward, but GitHub is better for a more organizational-wide, or a public level of engagement. With both workspaces containing many of...[Read More]


API Evangelist

An API Deployment Narrative

01 May 2020

This is the narrative from one of the last webinars I did for Postman oin my API-first e-commerce reference implementation Union Fashion. I always try to write what I am going to be saying furing a webinar so that it is loaded up in my brain in a natural way---think Neo learning Kung Fu before sparring with Morpheus. Anyways, here is the narrative, with accompanying video embedded below, helping share the narrative behind how I am building Union Fashion, trying to learn, grow, and expand how I use APIs out in the open, so that others can learn along the way. Jeff Jones the VP of Engineering at Union Fashion has been working to get more organized about how they deliver applications using APIs at the company. In our last webinar episode we looked at how Union Fashion was building and testing APIs, moving their operations towards an API first way of delivering application infrastructure. The build and test planning session was all about ensuring Jeff could lay the foundation for organizational change at Union Fashion by making sure his teams had the proper planning, and everyone was in agreement on an API-first way of delivering APIs behind the web and mobile applications they were needing to run their business—investing in the following areas to help define how they build and test APIs before actually building them: Organizational - Making sure the team was well defined, including having dedicated workspaces for each API. APIs - We are making sure that common API definitions at the center of the conversation for each API being developed. Collections - Being very structured in how collections are define and used to power different stops along the API life cycle. Environments - We made sure secrets and some key value pairs were abstracted away from each of the API collections. Mocks - Mock servers are published from all APIs, using a specific collection, making each API being developed more tangible....[Read More]


API Evangelist

API Deployment Collections - AWS API Gateway, Lambda, and RDS

21 Apr 2020

After over a decade of API evolution, API deployment is still much more of a dark art than it is something that ever sees the light of day. Sure you can setup a pipeline for an API, making a known pattern a repeatable process, but there isn’t much consistency out there when it comes to repeatable patterns for use across many different APIs. Certain vendors are working on optimizing the API deployment cycle within the context of their platforms, but I’ve always wanted to see more open blueprints for how APIs can be deployed, designed for applying across a mix of APIs which are defined using OpenAPI. To push this conversation forward I began exploring what the common patterns for API deployment on the leading cloud providers would look like, and if it was something I could accomplish using API infrastructure, which mean that I can do using Postman. One API deployment blueprint I had on my list to develops was using AWS API Gateway, Lambda, and RDS. Providing me with a quick way to consistent and repeatable way of deploying APIs that I could define as a Postman collection that can be shared and used by others. The results is a first draft of a Postman API deployment collection, which can be used to deploy an API to AWS using Postman, taking an existing OpenAPI and bringing it to life using common AWS solutions. Rather than outlining what I did as I normally would, I am going to play around with producing content in other mediums, and publish a video walk through of how my new AWS API Gateway, Lambda, and RDS API deployment Postman collection works—let me know what you think. My AWS API Gateway, Lambda, and RDS API deployment collection is still under development and being refined each week, but feel free to kick the tires and ask questions. I’ll be showcasing how the collections fits into the bigger picture of an...[Read More]


API Evangelist

API Deployment Collections - AWS API Gateway and DynamoDB

21 Apr 2020

After over a decade of API evolution, API deployment is still much more of a dark art than it is something that ever sees the light of day. Sure you can setup a pipeline for an API, making a known pattern a repeatable process, but there isn’t much consistency out there when it comes to repeatable patterns for use across many different APIs. Certain vendors are working on optimizing the API deployment cycle within the context of their platforms, but I’ve always wanted to see more open blueprints for how APIs can be deployed, designed for applying across a mix of APIs which are defined using OpenAPI. To push this conversation forward I began exploring what the common patterns for API deployment on the leading cloud providers would look like, and if it was something I could accomplish using API infrastructure, which mean that I can do using Postman. One API deployment blueprint I had on my list to develops was using AWS API Gateway and DynamoDB. Providing me with a quick way to consistent and repeatable way of deploying APIs that I could define as a Postman collection that can be shared and used by others. The results is a first draft of a Postman API deployment collection, which can be used to deploy an API to AWS using Postman, taking an existing OpenAPI and bringing it to life using common AWS solutions. Rather than outlining what I did as I normally would, I am going to play around with producing content in other mediums, and publish a video walk through of how my new AWS API Gateway and DynamoDB API deployment Postman collection works—let me know what you think. My AWS API Gateway and DynaoDB API deployment collection is still under development and being refined each week, but feel free to kick the tires and ask questions. I’ll be showcasing how the collections fits into the bigger picture of an enterprise API life...[Read More]


API Evangelist

Running and Organizing AWS Lambdas with Postman Collections

20 Apr 2020

I am auto-generating and manually producing a number of Postman collection lately. I am creating a Postman collection that autogenerates AWS Lambdas from an OpenAPI stored in the Postman API builder, as well as a handful of infrastructure AWS Lambdas that accomplish bigger picture items like creating a database in RDS, or zipping up AWS Lambda packages to deploy APIs. So, I have a lot more AWS Lambdas laying around that I am needing to organize and put to use. I find the first rule of AWS Lambda club is remembering you created the thing in the first place and remember to actually put the thing to use—when you have so many of them laying around, you need a way to make them more discoverable, browsable, and usable in your everyday lives, something Postman excels at. When it comes to deploying APIs with AWS infrastructure using a Postman collection, there were two things I couldn’t do purely with AWS APIs, which pushed me to create AWS Lambda functions that would get the job done. Demonstrating that I was going to be creating a growing number of Lambda functions that I was going to need to organize, retrieve, and execute regularly as part of my manual work, but also automated process, beginning with these two functions: Create AWS RDS Aurora SQL Table - There is no way to create a table using the AWS RDS API, so I created an AWS Lambda function that would let me pass in the table name and fields using environment variables, mounting the database and creating the table I needed. Generate AWS Lambda Deployment Package - I was dynamically generating a lot of the code powering Lambdas, as well as the layers of Node.js dependencies they were using, so I created a Lambda script that would take files from an AWS S3 bucket and folder and generate a zipped up AWS Lambda deployment package. I then created myself a Postman...[Read More]


API Evangelist

The Layers of the API Specifications, Definitions, and Schema Onion

18 Apr 2020

I struggle with using the right words in my API storytelling. Striking a blend between what people are saying across the sector, and what people should be saying. There are many words and phrases in the space that help describe what it is they do, while there are others that confuse more than they describe anything in particular. Mostly I struggle because all of this API stuff can be complicated and very abstract, but also because I can be a little dyslexic at times, seeing some words as interchangeable, depending on what day it is. To help me (once again) think through the world of API definitions, I wanted to riff off of my talk from AsyncAPI virtual conference this week and peel back the layers of the API specifications, definitions and schema onion. The words API specifications, definition, or schema are often used interchangeably as part of API discussions, but there are some realities on the ground when working with these artifacts that can increase the friction across operations if we allow them to be used interchangeably. It is pedantic as hell to want to write a story about the nuance of these terms, but if it helps me be more precise in my work, I’ll do it. To help illustrate the dimensions here, I wanted to highlight the artifacts around the Slack API that I am using for my talk next week. Slack Web API  OpenAPI - The OpenAPI for the Slack Web API defines the surface area of this single HTTP API instance. Slack Events API AsyncAPI - The AsyncAPI for the Slack Events API defines the surface of this real time HTTP API instance. These two artifacts describe the surface area of specific APIs, leveraging two open source API specification formats, but also adopting a third API specification format that these two specifications use to describe the underlying schema being used as part of the structure for request and response, message,...[Read More]


API Evangelist

We Should Have Built an API First

15 Apr 2020

It has been a while since I wrote a simple breakdown of why APIs matter, but also why API-First matters. I went down the API-First rabbit hole with API-First [Design || Code] and API-First [Business], but I haven’t just made the basic case of why we should have built an API in the first place. It really isn’t a concept you full grasp until you’ve made the very costly mistake of being API-Last several times over, so it makes sense to break things down into a single blog post to help folks [hopefully] learn from without going down the same paths I’ve been in my application development career. To help on-board folks with what I mean when I say API-First, let’s recap how we got here with a simple finctional product API story. One Product Catalog With Multiple Destinations Products are a ubiquitous resource in an online world. By 2000, if we were selling products in the real world, we also began needing to publish products to a website, which by 2005 would morph more into a mix of database-driven web applications. However by 2010, we also needed to have the same products available in our mobile applications., resulting in a handful of channels we need our products available on. Websites - Public websites that a product catalog need to be published to for consumption. Web Applications - Specific web applications that need access to our product clog. Mobile Applications - Making sure the product catalog is available via iPhone and Android phones. In 2020, these channels are morphing iton a suite of single page and static applications that work across web and mobile properties, but the need for a single set of content or data for making available across these channels hasn’t changed. By 2010, most companies were realizing that HTTP APIs were the most effective way to deliver content and data across applications, and by 2020 this has emerged as the reality for...[Read More]


API Evangelist

Growth in the Number of API Collections Over the Last Five Years

15 Apr 2020

There are surprisingly few meaningful API numbers to showcase across the API sector. There are few API or API service providers who have a view of the landscape that can produce meaningful numbers, and most prefer to keep their numbers close to their chests for a variety of reasons. Over the last decade we've all grown accustom to the Programmable Web hockey stock chart showing the number of public APIs added to the PW directory, due to the ubiquitous graphic being used in conference talks and blog posts since before 2010. I've always been a big advocate of API service providers developing and sharing their data, something that hasn't diminished at Postman. Postman has a pretty unique view of the API landscape, possessing many interesting data points. The company is working on a strategy for compiling, organizing, publishing, and sharing the data it has in a thoughtful way, something that you can see trickling out through a variety of slides from recent events like the Postman Galaxy Tour, and Postcon last year. Like this one showing the growth in API collections, topping at 34.9M collections published in 2020. The important thing with this visual is it reflects both private and public APIs. This graphis is just one of many data points Postman possesses that I am working to encourage packing up, so that others can reference and use, much like the ProgrammableWeb public API chart over the last decade. Visuals like this are important all of us making sense of what is going on, and be able to truly see the scope of what is happening. I'd love to see other API service providers share their numbers, but like Postman, I understand it is difficult to do in a meaningful way that respects the privacy of your users, and the interests of your investors. I will keep pushing for more observability into the API community through the Postman lens, and hopefully produce some interesting visuals...[Read More]


API Evangelist

Real Time Email Notifications About API Deprecations Down the Road

13 Apr 2020

I got an email from GitHub after firing up an older Postman collection I had. The collection was originally engineered to just pass in a GitHub token using a query parameter, which historically has been accepted, but is something that will be going away soon. It makes sense, and while query parameters are much easier for authentication, using headers is just a more logical and secure way to pass your tokens in with each API call. The token usage itself isn't what caught my attention, what gave me pause was the usage of real time email to notify users of features they are currently using which will be going away in the future. Here is the amil I got my GitHub about my usage of the deprecating access token query parameter: Hi @kinlane,On March 24th, 2020 at 03:55 (UTC) your personal access token ([TOKEN NAME) using [USER AGENT] was used as part of a query parameter to access an endpoint through the GitHub API:https://api.github.com/search/repositoriesPlease use the Authorization HTTP header instead, as using the `access_token` query parameter is deprecated. If this token is being used by an app you don't have control over, be aware that it may stop working as a result of this deprecation.Depending on your API usage, we'll be sending you this email reminder on a monthly basis for each token and User-Agent used in API calls made on your behalf. Just one URL that was accessed with a token and User-Agent combination will be listed in the email reminder, not all.Visit https://developer.github.com/changes/2020-02-10-deprecating-auth-through-query-param for more information about suggested workarounds and removal dates.Thanks,The GitHub Team I like this type of communication from API providers. I think this is a nice addition to any API management solution. Where you could flag any element of an API and when analytics reveals a developer using this feature, a transactional email is send off to the user. Allowing API providers to be more organized about how they plan for deprecations,...[Read More]


API Evangelist

Establishing an API-First Reference Implementation

06 Apr 2020

I do a lot of API blah blah blah’ing about abstract technical concepts. Sometimes I am able to craft a coherent narratives around some complex technology goings on, but most of the time I am just practicing. Workshopping different concepts until I find one that will make an impact on the way folks see APIs. One of the challenges I face in my storytelling is that I operate too far into the abstract, and not making the rubber meet the road enough. Another challenger I face is going too far down the rabbit hole with a particular companies implementation, which usually turns down the volume significantly on my storytelling, because most companies, organizations, institutions, and government agencies aren’t equipped to be 100% transparent about what they are doing. After a decade of storytelling exploration I find that operating somewhere in between the abstract and the real world is the best place to be, resulting in me desiring a reference implementation that I could use as an anchor for my storytelling, helping keep me grounded when it comes to how I talk about APIs. Welcome Union Fashion One of my co-workers at Postman had created a fictional company called Union Fashion when he started working on our solutions engineering team, but hadn’t put much more work into the project since. When I heard about it sounded exactly like what I was looking for. An e-commerce reference implementation that a wide audience could relate with, providing us with a model API implementation that we could use across webinars, workshops, and other storytelling channels. I’m big on building on the work of others, so I adopted Union Fashion, and I am working to define the fictional company as an API-First approach to operating a common real world business. Repo) (Docs) - Defining all of the products that Union Fashion offers. Orders - (Repo) (Docs) - Allows for the ordering of Union Fashion products online. Baskets - (Repo) (Docs) - Allows...[Read More]


API Evangelist

Crowdsourcing COVID-19 Testing Location Data

03 Apr 2020

I have been heads down working on resources for Postman's COVID-19 response, pulling together a variety of COVID-19 data and information that developers (and non-developers) can put to use when trying to make sense of what is going on around us. Identifying existing API resources that were available, while shining a light on the hard work of others was the first wave of our response, but along the way we identified some areas where there were no existing APIs, and felt there was an opportunity to step in. So I got to work on developing a couple of proof of concepts (POCs) that we could rally around as a company, and further contribute to the COVID-19 / Coronavirus fight. One of the POCs that came out of this work was an idea for crowdsourcing COVID-19 testing location data, resulting in a pretty interesting blueprint for making data available as APIs, which could be used for a variety of open data efforts—not just COVID-API testing locations. Framing the COVID-19 Testing Location Problem Before I dive into what I built, let me talk a little about how I landed on this being a problem in the first place, which is an important first step in any technological response to a real world problem. I was listening to the regular highlighting of drive-through COVID-19 testing locations during the press conferences coming out of this administration, and I was seeing or hearing it on the news I am digesting each day. Recognizing that the availability of COVID-19 testing locations was a politically charged topic, I wanted to better understand where we could or should go if we had Corona symptoms. I don’t have a doctor, event though I have health insurance, so I really have no idea where to go if I came down with it. I have anxiety about where I would go in my community if I came down with symptoms, and I can imagine that other...[Read More]


API Evangelist

COVID-19 Data and Information

26 Mar 2020

When it comes to coping with the stressful world unfolding around us I like to lose myself in my work. Data and APIs is a great way to tune out the world and keep myself busy while in isolation. Like most other technosolutionists I want to do some good in this crazy time, even if I don’t quite fully know what that means. So, to help me define what that means I sat down and began scratching at what was already occuring across the landscape. Identifying what sources of data were available out there, and what types of information was available which would truly make a difference in everyones world--not make it worse. Informational API Collections To begin I wanted to better understand where the top sources of information were, so I began documenting who the most relevant government agencies were in the COVID-19 conversation, going directly to the source of information at the highest levels. Center for Disease Control (CDC) (Website) (Collection) - A simple collection for pulling information from the CDC. European Centre for Disease Prevention and Control (ECDC) (Website) (Collection) - A simple collection for pulling information from the ECDC. World Health Organization (WHO) (Website) (Collection) - A simple collection for pulling information from the WHO. This seemed to reflect the authoritative resources available to me, so I got to work defining how each of these agencies shares information, mapping out the top channels I could profile as a Postman collection, aggregating relevant information, and then allowing it to be pulled manually or in some automated way. Twitter - Each agency uses Twitter as a way of providing updates. YouTube - Each agency uses YouTube to publish video resources. RSS / Atom Feeds - Each of the agency provides RSS feeds of info. I created a Postman collection for each agency, all someone has to do is enter their Twitter and YouTube API authentication, and they are up and running pulling data from across each of the agencies. My goal...[Read More]


API Evangelist

The Official Cloudflare API Postman Collection

12 Mar 2020

I use Cloudflare for my DNS. I like the threat protection they offer, the dead simple DNS management, and their robust API. I automate the management of a handful of my domains. Providing maintenance on 100 of my API life cycle, couple hundred API landscape sites, and the range of tooling, APIs, and other side projects I have. I’ve written several times about how Cloudlare weaves their API into their UI, so I am happy to write about their new Postman collection for the complete Cloudflare API. The Clouflare API Postman collection provides 447 individual API requests organized into different folders, making the entire surface area of the API much easier to navigation and make sense of what is going on. The Cloudflare API Postman collections gives you quick access to working with Users, Accounts, Organizations, Zones, DNS, Certificates, Workers, Firewalls, Load Balancer, Logs, and other essential infrastructure assets. I use about 1/20th of the valuable API resources Cloudflare provides, but I couldn’t operate my infrastructure like I do with out it.  I have added the Cloudflare API Postman collection to internal Postman workspaces, allowing me to automate more of API infrastructure work. I haven’t expanded my usage of the Cloudflare API because I haven’t had time to kick the tires and learn about what is going on. With the Cloudflare API Postman collection I am able to quickly play around with different APIs and learn more about what is possible. I’ve been wanted to play with Cloudlfare workers for sometime, and think more about how I can use them to deliver or consume APIs at the edge, and the Cloudflare API Postman collection makes it easier for me to make the time to learn more about how it all works. I’d love to see the Cloudflare API Postman collection get added to the Postman API Network. If you work at Cloudflare and are in charge of maintaining the Postman collection, all you have to...[Read More]


API Evangelist

A Proof of Concept API Service Tier

12 Mar 2020

If you  have followed me over the years you know that I get very frustrated by the access or lack of access to APIs, as well as the services and tooling that target the sector. As someone who is perpetually kicking the tires of API providers and service providers, not being able to on-board at all, on-board without my credit card, or one of the many other ways companies introduce friction, I find myself regularly pissed off. So anytime someone makes my world easier, and accommodates my need, desire, and obsession with playing with every damn API tool out there I have to say something. Today’s example is from my partner in crime Tyk, with their proof of concept option  Tyk acknowledges that most of us might not be ready for pro status—we just need to kick the tires a bit. I love this approach. It’s an evolution of the freemium model that I think is more honest and acknowledges the need to play around before entering in the credit card. This isn’t all about getting something for free or always being ready to pay for a service. This is about me getting access to your service, be able to develop my proof af concept (which I was able to do in < 10 minutes with Tyk), and then justify the cost of going pro with other stakeholders. Nice work Tyk—definitely what I like to see when playing with any API solution. [Read More]


API Evangelist

API-First [Business]

10 Mar 2020

I am working my way through defining a more precise definition of what API-first means which I can use across my API storytelling and conversations. I workshopped the widest definition possible of what API-First means to me yesterday, and be the end of the day I posted another more precise definition of what API-First means to a more technical crowd which I dubbed API-First [Design || Code]. Today, I’m once again thinking more about the business side of the conversation, and focusing on what I would like to eventually be a more precise definition of what API-First means to business stakeholders, which I am dubbing as API-First [Business]. As I said in my broader definition of API-First, if these conversations aren’t including business stakeholders we are doing it wrong. These people are making many of the decisions around the why and how of the desktop, web, mobile, device, and network applications we are delivering on top of our API infrastructure, so we can’t argue that API-First is a developer or technical only concept. We need business stakeholders also thinking API-First, otherwise our projects will never have the resources they need, and are more likely to fall short in meeting real world business objectives. API-First is not a developer concept, it is a concept that business and developer audiences should both be aware of, and then there are separate inner cores to the definition of API-First, one API-First[Design || Code], and the other API-First[Business], which can help bring a more precise definition to the table for each dimension of our operations. Some Common Business Productivity APIs To help make this definition a little more real I wanted to actually apply it against a handful of services I am currently working with business stakeholders at Postman. I am working with some very smart technically savvy folks who aren’t programmers to understand how I can help them be more effective and efficient in their daily work. Working together,...[Read More]


API Evangelist

What Is API First?

09 Mar 2020

I really struggled with this piece on API-first. It is one of those holistic API advice pieces I am very conflicted about. API-first feels like yet another marketing phrase or latest trend like microservices. So as I am writing down my thoughts over the last couple weeks on this, my bullshit-o-meter kept going off. Honestly it still is, but I still feel like there is enough value here that I can move forward with a story. As my co-worker Joyce rightfully pointed out in a meeting recently, API-first is one of those phrases we regularly throw out there without much assessment, agreement, or real definition of what it means. That is one reason it feels so wrong at times, because I feel like it is one of those feel good things we throw out there, but never really think too deeply about while doing, or after it fails and we’ve moved on to the next thing. With all of that said, I still believe that API-first can matter, if we, as Joyce points out, actually define what we mean by it. I think there is a lot of misconception about what we mean by API-firsat, and I’d like to stimulate conversation around what it means, if not just get more precise around how I talk about it. One concern I have about the API-first discussion is that once again it is something that only concerns developers when delivering APIs, and that it is something that business folks shouldn’t worry their pretty little heads about. This is a classic historical technique for dividing and conquering the technology-human paradigm that is spreading across society, and is something I am not interested in perpetuating. So I have broken down API-first discussion into two main parts, one through the technical lens, and another through how business folks will need to be made aware of as they continue to employ technology as part of their everyday work. Looking Through the...[Read More]


API Evangelist

API-First [Design || Code]

09 Mar 2020

I worked through my thoughts on what API first is, which I consider to be the outer layers of what is going on when we use this phrase. I wanted to focus on the technical and business rift that exists in this discussion first, now I want to dive into the more technical core of this phrase, and get to the heart of how developers are going to see this phrase. Depending on the type of developer you are, and your exposure to different aspects of the API industry or API operations within your organization you are going to make different assumptions about what API first is or isn’t. Some will feel it is more just about doing APIs before you build applications, while others are going to see it as being more about going API design first, before you ever write any code. Ultimately I want to establish a definition of API first that is inclusive, and not pushing people out, while also helping me ground how I use the phrase. Let’s Recap, What Is API-First? From the previous post, let’s take a fresh look at what is API-First from the vantage point of a more technically included stakeholder like architect, developer, or other IT actors. Setting the stage for how API-First [Code] can be approached. Before developing a web application, develop an API first Before developing a mobile application, develop an API first Before developing a device application, develop an API first Before attempting any system integration, develop an API first Before directly connecting to a databases, develop an API first Also, Why do API-First? Naturally people will ask why? To help flesh out why API-First matters, before we help separate API-First [Code] from API-First [Design], let’s look at the benefits of going API-First, then separate code from design approaches might make a little more sense. Allow potential stakeholders to communicate about what is needed before applications are actually build. API will reduce...[Read More]


API Evangelist

What Is My API Network

06 Mar 2020

I am working on the vision for the Postman Network. As I do with everything, I want to start with the basics human aspects of what is going on, and then relate them to the more technical and then business aspects of it all. Right now, the Postman Network is a listing of teams and individuals who have published Postman collections under a handful of categories. While visiting the network you can browse collections by category or search by keyword, and view the team or individual profile, select the “Run in Postman” button, or view the documentation. My goal is to brainstorm what is next for the Postman network, but also help define what network means in a world of API collaboration. When it comes to my API network, I like to focus on the meaningful elements, the “person, place, or thing” that makes my world go around. I am not interested in nouns that do not enrich my world, and I am keen on emphasis of the humanity of all of this over purely the tech for the sake of tech. So what are the nouns that make up my world? People - While I don’t always like people, because I am one, they tend to be the center of my world. People are the most important building block of my network, and drive what I truly care about when it comes to APIs. Teams - I engage with a variety of teams as part of my job, both internal to Postman, but also externally across the many different enterprise organizations I am working with. While I have relationships with individuals on the team, I find myself regularly thinking about how to add value to the entire team, and influence how and why they are doing APIs. Projects - My world is littered with projects. Some projects move forward, while others simmer, and sometimes whither on the vine. Projects usually involve one or many...[Read More]


API Evangelist

The Building Blocks of API Partner Programs

04 Mar 2020

I’m doing a deep dive into partner API research, taking a fresh look at how API providers and service providers are operating their partner programs. I looked through around a hundred partner programs I have indexed, and listed a few of the notable ones below. It can be difficult to study partner API programs because many organizations consider their API program a type of partner program by itself, and then there are also a lot of partner APIs, providing actual services involving partners, providing programmatic access to a variety of partner resources. I’ll be rolling up this research into several other more formal strategies and guides that I will publish as part of API Evangelist, but like I do with all my work I wanted to publish my notes and research here as I’m working through. Purpose The reasons behind having a partner program, and what value it brings to an organization and its partners. Providing a list of reasons why you will want to invest in a partner program, and use to sell the concept to other stakeholders. Increase Exposure - Providing more exposure opportunities for platform partners. Increase Skills - Expand upon the skills of partners who are putting a platform to work. Increase Awareness - Grow the awareness amongst partners about what is possible. Increase Sales - Making it about the money, and expanding the sales intake for partners. Drive Communications - Push the platform and its partners to communicate more. Increase Collaboration - Pushing partners to work together, and with the platform more. Encourage Usage - Incentivize more usage of the platform and its products and services. Encourage Adoption - Drive adoption of the platform, pushing partners to depend on it more. Encourage Syndication - Increase the syndication of content and other branded assets. Opportunity for Growth - Allow partners to grow by using the platform more. Protect Users From Unwanted Behavior - Solicit partner assistance to help keep users safe....[Read More]


API Evangelist

Postman API Reference and Capability Collections

04 Mar 2020

Postman collections are a great way to document every detail of an API, defining the host, path, parameters, headers, and body of each API request. Allowing any single API request to be captured as a machine and human readable Postman collection that can be shared and used by any technical or non-technical user. The most common approach to defining a Postman API collection is to document the requests across all available APIs, providing a complete collection of all API requests that can be made, then using that reference to mock, document, test, monitor, and execute individual requests manually or as part of any automated process.  However, there are other ways to evolve these requests to ensure that they more closely resemble common business tasks, accomplishing everyday activities that technical and non-technical individual need to accomplish. An AWS EC2 Reference Collection An example of a Postman reference API collection can be found in the collections I worked on leading up to AWS re:Invent last December. One of the reference API collections I have been crafting is for the Amazon EC2, providing a portable and executable collection of all API requests possible for the cloud compute platform. The AWS EC2 reference collection has over 350 individual requests possible in, providing a dizzying amount of control over delivering, operating, and evolving compute capacity across AWS regions. While this collection a robust representation of all the available AWS EC2 resources, it will take additional work to understand what is possible, find the specific request needed for any particular integration or application, and populate the request with relevant values to realize any specific business need. It is a great start when it comes to putting AWS EC2 to work, but to make things more usable, it will take a little more work. An Amazon EC2 Capability Collection This AWS EC2 reference collection provides a foundation for delivering integrations and applications, and can be used as a seed for a different...[Read More]


API Evangelist

Peeling the OpenAPI-Driven API Life Cycle Collaboration Onion

03 Mar 2020

I am trying to better understand how we all work together to deliver and consume APIs. Fleshing out more meaning behind some of the common words we use in the space such as collaboration, platform, hubs, workspaces, feedback looks, comments, sharing, notifications, and other communication channels. I want push my thoughts forward on what the gears of API collaboration are, and how we can better work together to move many different APIs forward as provider and consumer. API collaboration isn’t very straightforward, and in my mind there are several layers to how things actually are playing out across the API landscape. This is my best attempt at breaking things out into different buckets for helping us make sense of how we are working together to move API infrastructure forward at the organizational and industry level. Layer One - Single OpenAPI Management In 2020, OpenAPI has won the great API specification wars of the previous decade. OpenAPI is helping individual developers and architects more efficiently define and design OpenAPI definitions, using the core objects of the API specification as our guide. Providing us with a box of gears we can assemble to define the floor of our digital factories putting out the digital products and services we provide to our customers each day. Info - Helping manage the name and description for OpenAPI definitions Contact - Helping integrate and manage contact info as part of wider team management. License - Helping manage the4 licensing for the APIs being defined. Server - More management for available servers (ie. mock, development, production, etc) Server Variables - Helping manage server variables as part of environment management. Paths - Help managing the design and definition of API paths. Operation - Better operation management (verbs, summary, description, operationIds, etc.) Parameter - Help more consistently name and define query and path parameters. Headers - Be more deliberate and aware about how headed are defined and used. Request Body - More tools for...[Read More]


API Evangelist

The Technology, Business, and Politics of the OpenAPI Conversation

02 Mar 2020

I was pondering a tweet from Aidan Cunniffe (@aidandcunniffe) over at Optic they other day.  He was expressing what he says is a “controversial opinion that keeps getting backed up by conversations. Each version of OpenAPI and JSON Schema map to ~15 versions. All the implementations by vendors, cloud providers, and open source libs implement a useful (but not always the same subset.” I don’t think it is a controversial opinion at all, I think he points to a pretty critical deficiency in our belief around APIs and specifications like OpenAPI. Something that begins with the specification itself and how it evolves, but as Aidan points out, echoes out through API service and tooling providers, but then also across API providers themselves who put the OpenAPI specification as part of their own operations.  On Twitter, Aidan continues with, “what is the point of a data-spec if it's not enforceable the same way, everywhere? We have to acknowledge that there's no one spec (a versioned markdown file doesn't count), there's 15, 20, 30, 50 of them in the wild today -- and that's blocking teams from using tooling end-end.” Then continues by suggesting “a wasm reference implementation that every vendor and lib could drop-in and link to across programming languages might actually solve this problem and truly enable end-end use of OpenAPI I'd make this objective #1 for 2020 if I had the keys. I just have the tweets :)”. Makes sense to me, and I’d say something that the OpenAPI community should adopt. Honestly, and I’ve made the argument before, I think the OAI should be investing to stabilize core OpenAPI tooling, going beyond just the spec.  Technical Solutions Require Business and Industry Political Understanding I support the technical solution Aidan puts forward, and would love to see investment across multiple providers to make happen. However, I think we will need to better understand the business and politics of it all to see the change we want—consistent support of...[Read More]


API Evangelist

Design and Build API with Postman

25 Feb 2020

I am doing more talks and workshops within enterprise organizations educating teams about designing and building APIs, helping Postman customers be more successful in not just using Postman, but in defining, designing, delivering, supporting, and evolving high quality APIs using Postman. 90% of the teams I work with are still build-first when it comes to delivering API capabilities across the enterprise, so we are invested in helping bring that number down. Empowering teams to go API-first when it comes to designing and building their APIs, moving beyond the more costly approach of writing code first, and develop more healthy practices that involve business and technical stakeholders in the process. It is natural for developers to want to roll up their sleeves and begin coding to deliver an API. It is what they are trained to do. However, it makes a lot more sense to involve business stakeholders earlier on in the process, and avoid the costly, isolating, and more time intensive approach of purely approach APIs a writing code. API has been working internally, and with our most engaged customers to better define what an API-first workflow involving the following stops along the API life cycle: APIs Builder - On the Postman platform, all APIs begin with the new APIs tab—the beta implementation of being able to manage the API life cycle within Postman. Create - You can create a new API by starting fresh, or importing an existing API definition in the OpenAPI, RAML, or GraphQL formats, and use it as the definition for each new API> Definition - To change the design of an API, you can directly edit the OpenAPI, RAML, or GraphQL definition, manipulating the design of the API and the underlying schema. Mock - With an API definition you can then mock each API, providing a virtualized representation of each path, with examples returned as mocked responses. Environment - Defining key / value pairs and globals that can be used...[Read More]


API Evangelist

Managing API Secrets Using Postman Environments

24 Feb 2020

Postman environments are machine readable definitions of design, development, staging, and production environments that can be used across API operations. When used properly they contain the keys, tokens, and other secrets needed for authorizing each individual, or collection of API requests. Making them an excellent place to begin getting more organized about how API secrets are applied, managed, and audited across teams. Secrets can also be littered throughout Postman collections, but when collections and environments are used properly, developers should be isolating secrets to environments, helping make sure Postman collections contain the technical details of the surface area of an API, but the unique values applied to each API is actually present as part of well defined Postman environments. Providing the opportunity for managing and governing how API secrets are being applied and stored by developers, and opening up the opportunity to use Postman as part of wider API governance efforts. Environments are an essential building block to be considered as part of wider API governance strategy. Like Postman collection, environments will need the greatest amount of governance to inject the most observability, reliability, and security across API operations. When used right, Postman environments help isolate and standardize how secrets, PII, and other sensitive information is used across the delivery and integration of APIs. Allowing for centralized control over environments by leveraging Postman for the managementof environments through the interface and the API. GUI - Managing all of the environments in use with the Postman web interface. All Environments - Manually manage all of the environments in use using the central Postman web interface, allowing any member of governance to audit how environments are being used. API - Automating the management of environments using the Postman API, opening up the opportunity for auditing, managing, and enforcing governance at scale across the environments being applied by all enterprise teams engaging with API operations. All Environments - Programmatically pulling all environments via Postman API, so that they can evaluated...[Read More]


API Evangelist

Content Negotiation for APIs and the Web

24 Feb 2020

APIs often seem like another one of those very technical acronyms that only the most technical people will care about. If you don’t aspire to be a software developer, why should you ever care about what application programming interfaces (APIs)? To push back on this notion I regularly push myself to make APIs more accessible to business users. I feel it is important that anyone who use the web daily as part of their professional career should possess a working understanding of the tool(s) they depend, and have a grip on how APIs aren’t some add-on to the World Wide Web we depend on each day--understanding that APIs and the web are one and the same. Over the last twenty years the web has became a fundamental aspect of how we do business online, and APIs are just the latest evolution of how the web is being put to use to use as part of the digital transformation businesses are going through across every business sector today. The World Wide Web, commonly known as the Web, is an information system where documents and other web resources are identified by Uniform Resource Locators, which may be interlinked by hypertext, and are accessible over the Internet—with “documents and other web resources” being the bridge between APIs and the web. If you are using the web you can use APIs, as long as you understand one of the fundamental building blocks of the web--that you can negotiate “documents and other web resources” in the following information formats. Hyper Text Markup Language (HTML) - Each time you use the web you are getting and posting HTML documents using the Internet. HTML is a machine readable format that renders each web page you view, helping make easier for humans to read in a variety of languages. While you may not write HTML or directly “read” HTML, you are using HTML each day as you make your away around to different web...[Read More]


API Evangelist

The Caltech University API Landscape

19 Feb 2020

I regularly take a look at what different universities are up to when it comes to their APIs. I spent two days talking with different universities at the University API summit in Utah a couple weeks back, and I wanted to continue working my way through the list of schools I am speaking with, profiling their approach to doing APIs, while also providing some constructive feedback on what schools might consider doing next when it comes to optimizing API delivery and consumption across campus. Next up on m list is Caltech, who we have been having conversations with at Postman, and I wanted to conduct an assessment of what the current state of APIs are across the school. The university reflects what I see at most universities, meaning there are plenty of APIs in operation, but not any visible organized effort when it comes to bringing together all the existing APIs into a single developer portal, or centralizing API knowledge and best practices when it comes to the interesting API things going on across a campus, and with other partners and stakeholders. APIs in the Caltech Library When it comes to APIs at the University level the first place to start is always at the library, and things are no different at Caltech. While there is no official landing page specifically for APIs the Caltech library has GitHub page dedicated to a variety of programmatic solutions https://caltechlibrary.github.io/, but you can find many signals of API activity behind the scene, like this API announcement that the write API is available https://www.library.caltech.edu/news/write-api-now-operational. You can also find an interesting case study on how the library is using APIs provided by an interesting API provider called Clarivate, which I will be looking to understand further. As with every other university, there is a huge opportunity for Caltech to be more organized and public about the API resources offered as part of the library--even if it isn't widely available to...[Read More]


API Evangelist

API Interrogation

14 Feb 2020

I was doing some investigation into how journalists are using APIs, or could / should be using APIs. After some quick Googling, Binging, and DuckDuckGoing, I came across a workshop by  David Eads of ProPublica Illinois, called a A hitchhiker's guide To APIs. As I began reading, I was struck by how well it captured not only usage of Postman in journalism, but also how well it captures what Postman does in general in a single precise sentence, “In this hands-on session, you will use Postman to interrogate a web API.” That is how I use Postman. That is why 10 million developers use Postman.  APIs are how we can interrogate the digital world unfolding around us. It is increasingly how we can interrogate the digital world emerging across our physical worlds. I like the concept in general, but definitely think it is something I should explore further when it comes to journalism and investigative storytelling. Postman provides a pretty powerful way to get at the data being published by city, county, state, and federal government. It also provides a robust way to get at the social currents flowing around us on Twitter, Facebook, LinkedIn, and other leading platforms. Postman and APIs provides technical and non-technical users with what they need to target a source of data or content, authenticate, and begin interrogating the source for all relevant information. I find that interrogating a startup is best done via their own API, as well as their digital presence via Twitter, LinkedIn, GitHub, Stack Overflow, Facebook, Youtube, and Instagram using APIs, over speaking with them directly. I find that interrogating a federal agency is often only possible through the datasets it publishes, providing me with a self service way to understand a specific slice of the how our society works (or doesn’t). While I can interrogate a company, organization, institution, and government agencies using their websites, I find that also being able to interrogate their platform,...[Read More]


API Evangelist

All of the Discussions from the BYU API University Workshop in Utah

12 Feb 2020

I went to Provo Utah a couple weeks ago and participated in the sixth annual Brigham Young University (BYU) University API Workshop. I was the keynote opener for the first edition of the conference, and I was the same for the sixth edition of the event bringing together many different universities together to talk about API usage across their campuses. When the event began it was primarily BYU staff, but it has expanded to include administrators and faculty from what I counted to be over twenty other universities from across the United States--making for a pretty interesting mix of conversation from higher education API practitioners looking to solve problems, and share their stories of how APIs have help make an impact at how universities serve students and the public. The University API Workshop is an “unConference Focused on University & Personal APIs & Their Use in Improving Learning”. It brought together around one hundred folks to discuss a wide variety of API topics. Since it was an unconference, everyone pitched their own ideas, with some of them being about sharing API knowledge, while others was about soliciting knowledge from the other attendees. Resulting in a pretty compelling list of session spread across two days. You can browse through the sessions using the Google Docs that every session organizer published. Providing a pretty compelling look at how APIs are making an impact at the higher education level, shining a light on the concerns of API stakeholders across the campus. Session One Let’s stop using usernames & passwords User Experience in the API World Postman Fundamentals Securing APIs/data with proper authorization Session Two Walk, Talk, and API Stalk API Governance at Scale taking ideas to consistent execution Mendix (HPAPaaS/Low Code) After a Year at BYU Our New NGDLE | Open Courses Made With Web Components, Microservices, Docker, CI/CD and more! DDD vs. BI - Balancing Centralizing and Decentralizing Forces in Data Architecture Session Three How do I test...[Read More]


API Evangelist

Postman Governance as the Foundation for Wider API Governance

11 Feb 2020

This an overview of possible strategies for governing how Postman is used across a large organization. It is common for Postman to be already in use across an organization by individuals operating in isolation using a free tier of access. Governance of not just Postman, but also the end to end API life cycle begins with getting all developers using Postman under a single organizational team, working across master planned workspaces. If there are concerns about how Postman is being used across an enterprise organization, governance of this usage begins by focusing on bringing all enterprise Postman users together under a single license, and team, so that activity can be managed collectively. Postman Users Over the last five years Postman has become an indispensable tool in the toolbox of developers. 10 million developers have downloaded the application and are using it to authorize and make requests to APIs then debug the responses. The benefit to API operations for the enterprise is clear, but the challenge now for enterprise organizations is to identify their individual Postman users and encourage them to operate under a single pro, team, or enterprise license.  Currently users are operating in isolation, defining, storing, and applying secrets and PII locally on their own workstations within Postman, and syncing to the cloud as part of their regular usage of Postman—isolating details about APIs, secrets, potentially PII, and other sensitive data within these three areas. Personal Workspaces - Storing collections, and environments within their localized personal workspaces and individual Postman account. Personal Collections - Developing API collections in isolation, leaving them inaccessible to other teams, and reusable across operations. Personal Environments - Using environments to store secrets, PII, and other data within their localized personal workspaces and individual Postman account.  When it comes to enterprise API governance, observability, and security, the problem isn’t with Postman being used by developers, the problems is developers are not using Postman together under a single license, across managed shared workspaces. Putting...[Read More]