The API Evangelist Blog

API Evangelist

Nobody Likes Specifications - @jeanqasaur

04 Mar 2021

Jean Yang from Akita Software pinged some of us in the API community with "People don't like specs. There's a long history of people not liking specs." @thatplguy on how we need a new term for [PLACEHOLDER WORD] that we infer from behavior, since people think specs are things that take work to write and get out of date.” I wanted to riff off all the great ideas from folks who replied, and see where I could go with the concept. I am fine with the term specification, but as a storyteller I get the power and potential of finding exactly the right word to describe this. I also get that people don’t like doing things that sound like work, and if we can come up with a term or phrase that softens things up, making it friendlier and more accessible, while retaining all of the essence of what API specifications, I think it could move the needle on API spec literacy and practice amongst the masses of people waking up to APIs in 2021. I see singer and songwriter Matt McLarty (@MattMcLartyBC) suggest models in response to Jean—here are my thoughts piled on Matt’s: Models - I like this one. I agree that we are modeling all the moving parts of our operations. Working together to model all of our API capabilities makes a lot of sense. I would say it begins to break down though as a concept as we move into production. The closest definition of model to this situation is, “a system or thing used as an example to follow or imitate.” Is it sufficient enough to take us through the entire lifecycle? IDK... Then I see Harry Potter, er I mean my friend Michael Hibay (@hibaymj) suggest languages and vocabularies, to which I pile on my own thoughts: Languages - I worry this is too ambiguous and will get lost in the shuffle--not translate globally. Vocabularies - I feel like...[Read More]


API Evangelist

Validating the FHIR API Contract as You Use the API and Then Leaving Inline Comments on the OpenAPI

03 Mar 2021

I am working with the OpenAPI for the Fast Healthcare Interoperability Resources (FHIR), getting more familiar with the specification as I get strengthen my awareness of the CMS Interoperability and Patient Access Final Rule. I have the OpenAPI for the FHIR specification published to a public API workspace, and a collection I generated from it to help me document, mock, and apply contract tests for FHRI APIs, helping ensure they are compliant to the healthcare API standard. As soon as I ran my first request against a sandbox FHIR API I was provided with two alerts letting me know the response was out of sync with the actual spec. These are pretty simple, yet critical structural issues in the way the OpenAPI is defined that doesn’t actually match the API implementation. I am still unsure if it is the OpenAPI that is wrong, or the sandbox API implementation, so I am just going to leave a comment on the individual API method in the OpenAPI, letting me revisit later and resolve each issue once I have the answer. I am going to play with more of the API before I submit the issue with the FHIR working group, or at least who is in charge of the OpenAPI for the FHIR specification. I am looking to create a suite of validation collections for the API specification that can be run manually, scheduled and run regularly, or triggered as part of a CI/CD pipeline, so I need to make sure the OpenAPI and derivative collections are correct before I publish them, making them available to Postman healthcare customers who are looking to validate their APIs. Ensuring that healthcare APIs are following the FHIR specification down to the detail will be critical to achieve the interoperability the CMS Interoperability and Patient Access Final Rule is looking to accomplish. [Read More]


API Evangelist

Managing Multiple Versions of the UK Open Banking OpenAPIs in a Public API Workspace

03 Mar 2021

I pushing forward the documenting and certifying of UK public APIs in a public workspace. Historically I only had a single OpenAPI definition for each of the six public banking APIs, but as part of pushing forward my work I wanted to have multiple versions for each of the APIs. The UK government mandates that all banks have each of the six public APIs following a common definition, which provides the perfect set of APIs to demonstrate the possibilities of applying common industry API standards. However, to show the power of public API workspaces I needed to be able to show the change that occurs across each of the APIs being maintained over time. This image shows four separate versions for the ATM locator API. I chose to only do version 2.0 of the API for now, and maybe once I have a little more bandwidth I will be able publish the older versions as well. Once I prove out some of the concepts I want to push forward I am looking to tell the change narrative that exists across each of the APIs since they were born. Before I move to far with my work I need to validate and certify each of the fifteen banks I have environments published for, helping me certify each bank’s API to the core OpenAPI specification. I downloaded the Swagger 2.0 files from the Open Banking UK wiki, but then chose to upgrade them to OpenAPI 3.0 before I imported into Postman. The work I am doing involves using the OpenAPI 3.0 components object and some other capabilities that do not exist in 2.0 of the specification. Ideally, the official working group managing the specification would migrate to the current version of the spec, but I’ll address that as I work with them to help me take over the public workspace for the UK public banking APIs. I am looking to establish a suite of collections that can...[Read More]


API Evangelist

Open Data Using Postman Collections

17 Feb 2021

I am pushing forward how Postman can be used for public data. I have a whole mess of different data sets I need available for different projects I am working on. For one project I am aggregating ten separate environmental data sources available as a mix of CSV, JSON, and excel files, as well as a couple of actual APIs. I am looking to build an embeddable dashboard widget using data across these ten sources, and I am looking to organize all of them via a single public workspace, helping normalize them all as simple APIs returning CSV or JSON. The project is just a POC, and once it moves toward production we’ll launch actual APIs, but for now I am able to mock them using Postman. The process got me thinking about how this approach can be used to make simple public datasets available via forkable Postman collections. Simple Data APIs Using Collections As I began aggregating the datasets into Postman, the first couple of datasets were pretty basic. Simple CSV or JSON files, and a couple basic APIs. I just created a collection, added a new request, and pasted the URL into the request and pulled the data from the source. Once I had the response from each API I would save the response as an example for the request. Then the entire CSV or JSON would be stored locally within the collection. For most of them I’d convert the data to, or from JSON or CSV, and add a parameter property so that each response could returned depending on what format the consumer desires for the visualizations. Now that I have an example stored for each dataset as part of the collection I can mock the collection, making the data available as a simple “mocked” API. This approach provides a public or private URL I can share with anyone who is building a prototype application-—in this case a widget. Going from dataset...[Read More]


API Evangelist

Gathering My Thoughts on API Discovery

11 Feb 2021

I am working to load up all my API discovery experiences into my head for some upcoming conversations. So I sat down and pulled together a summary of my API discovery research to date to help refresh my memory of what has happened and how we got here. API discovery is the one of the few layers of the API space that I am personally committed to helping move things forward and being able to see all the moving parts together helps me keep doing this. Let’s take a stroll through my memory of the evolution of API discover over the last fifteen years so that I can speak more coherently about all of this with a variety of folks. ProgrammableWeb ProgrammableWeb was the first source of being able to discover API, and in 2020 it is still the place you go to find APIs. Really not much has changed in the last fifteen years with ProgrammableWeb except for the owners and operators, and the look and feel of the site. It is still where you go to look for new and existing APIs, and where you find APIs when Googling. I have fond memories of writing for ProgrammableWeb, and the site is still a great source of information for me, but I am left frustrated that PW hasn’t moved forward the API discovery conversation in any interesting ways over the years. I just think it is a missed opportunity, and reflects much about the API space that I think holds us all back. Mashape -> Rapid API After ProgrammableWeb, the next evolution in the API space when it came to API discovery was Mashape, which is now known as Rapid API. The API marketplace was born out of the age of API management and provides basic management capabilities alongside with API discovery services. Providing a pretty rich set of APIs you can search and onboard with using the Rapid API marketplace. Mashape and Rapid...[Read More]


API Evangelist

API Storytelling with Mike and Aidan

11 Feb 2021

If you have followed my work you know that I like telling stories. Stories are the single most important tool in my Chief Evangelist and API Evangelist toolbox. None of the code matters in my opinion, and the stories surrounding the code is what makes the actual impact on our reality. The stories we tell each other, as well as the stories we tell ourselves. Everything in the world of technology and APIs is made up of stories. I am hovering around 5000 stories here on API Evangelist, which reflects everything I am when it comes to API Evangelist. Stories are how I make sense of the API world that has unfolded in the last twenty years. Storytelling is how I work through all of the things I do not understand, moving everything API from a very abstract realm into something that is more tangible, visible, and sometimes more meaningful to me in the real world. I couldn’t have done any of this without stories. Throughout my storytelling as the API Evangelist I have also taught myself to work through my own personal baggage over at kinlane.com. Applying the same methodology to my past and figuring out who I am today. API Evangelist has always been very much a performance, but the storytelling I engaged in as part of the performance went much deeper than being just a business production. Over the years, both of these streams of storytelling (apievangelist.com & kinlane.com) have influenced others in the world, having an impact on their storytelling, or help them embark on their own storytelling journey. I’ve learned a lot from these engagements, and made a lot of friends around the world because of a shared love for storytelling. This shared storytelling journey has recently manifested itself as a video conversation between Mike Amundsen (@mamund) and Aidan Cunniffe (@aidandcunniffe), which we are simply calling API Storytelling. We only have one discussion under our belt and we aren’t quite...[Read More]


API Evangelist

Making Sense of the Different Types of API Testing

30 Jan 2021

I have to admit something. I don’t fully grasp the entire landscape of API testing. I mean, I have a pretty decent awareness and experience in testing APIs, but I can’t close my eyes and coherently break down each layer or type of testing, let alone competently navigate the many different types of services and tooling available on the market for API testing. Like most other dimensions of the API universe the content and guidance on the subject of API testing is all over the place. After a couple of hours Googling and making my way through my bookmarks, I uncovered a pretty expansive dictionary for what I’d consider to be under the umbrella of API testing. First off, I have to talk about API testing in the most general sense before I get into the more and less formal API testing approaches. It was a dimension of API testing I hadn’t considered before I began working at Postman, but API testing meaning that I am just kicking the tires on a API, learning what it is all about, and how you use it. This is what the majority of Postman’s 13 million users are doing when they say they are testing an API with the Postman platform. THis experimental and curious approach to API testing provides a great onramp to the world of API publishing and consumption, but does little to help us articulate what API testing is or isn’t. Beyond just “testing out” an API, from what I can gather across about 25 separate API testing articles, there are 25 different layers to the API testing onion: Validation Testing - I am guessing a general type of validation — seems pretty broad. Functional Testing - Adopted as part of code testing practices, applied to unit of code. Component Testing - Similar to functional, but testing based upon small unit of compute. User Interface Testing - Testing of the API in the context of...[Read More]


API Evangelist

Keeping API Entropy Low is Needed to Continue API Growth and Expansion

30 Jan 2021

I love the word entropy. It means so many things to so many different people. In means different things in the physical realm versus the informational or virtual realms. It is one of those big words you can say to confuse people, or actually get yourself in trouble being able to actually defend your position on what entropy means when around smart people. It is said that famed mathematician John Von Neumann had told fellow mathematician and creator of Information Theory that he should use the word entropy instead of information because that no one understands entropy and then you can win arguments about your theory. I also read that Shannon and Norbert Weiner also dueled over the meaning, seeing it in very opposite ways. I like the word for all of these reasons, but mostly because of its relationship to uncertainty.  In the realm of physics entropy means, a thermodynamic quantity representing the unavailability of a system's thermal energy for conversion into mechanical work, often interpreted as the degree of disorder or randomness in the system In the more virtual realm of information theory, the entropy of a random variable is the average level of information, surprise, or uncertainty inherent in the variable's possible outcomes. While I could easily use entropy as a metaphor for APIs in the physical sense, it is really the appropriation of it for information theory that really brings it home for me. Entropy in Shannon’s time was centered around noise or static in communication, but when you look at how APIs enable communication between systems, and allowing web, mobile, device, and network applications to communicate, this static or noise reveals itself as friction, errors, outages, instability, unreliability, and misaligned business and political priorities.   Think about the level of information one encounters when it comes to putting APIs to work these days. Consider the surprise one encounters when seemingly similar API resources speak entirely different dialects or behave inconsistently. Stop...[Read More]


API Evangelist

Examples of Minimum Viable and Complete Landscape APIs.json Index Files

29 Jan 2021

I am preparing for the next version of APIs.json and I am taking another pass over what the specification is, but also taking a fresh look at why the specification exists. Part of this fresh look involves assessing what I consider to be the low bar for an APIs.json index, as well as what the entire scope might look like. To help me (and you) understand the scope of what APIs.json or APIs.yaml can do when it comes to indexing our API operations and making them discoverable in a machine readable way. The most important thing to remember about APIs.json is that it is all about indexing API operations in a way that acknowledges that there are two sides of this API integration game which need to be indexed and made discoverable across an organization. Human Readable - Providing URL references for the aspects of API Operations that human stakeholders will need to understand what is happening with APIs and how to put them to work in applications. Machine Readable - Providing URL references for aspects of API Operations that are system and applications can use to make sense of API Operations, accessing as a machine readable definition. APIs.json is about indexing all of these human and machine readable aspects of our API Operations with an emphasis on evolving human readable elements to also be machine readable so that as much of the surface area of our API operations is indexable by other systems and applications as possible. There is another dimension of APIs.json as a specification that is helpful to understand beyond the human and machine readable elements, by providing a vocabulary for describing two separate scopes of API operations, helping define the scope of information provided. API Specific Properties - References to details about a specific API, providing human and machine readable details about an API, so that consumers understand everything that is possible. Common Properties - References to details that support all...[Read More]


API Evangelist

Evaluating APIs.json API Property Types Alongside OpenAPI Extensions

23 Jan 2021

I am giving some much needed love to my APIs.yaml and API.json API discovery format while using the work to also just think about the wider API landscape. This is the original intent behind APIs.json…to help me make sense of the API landscape.  Most folks are thinking about APIs as a producer, or as a consumer—hopefully both. However, there are fewer people who also pay attention to the entire API landscape, and APIs.json emerged out of this need for me in 2014. In 2020 I find myself totally immersed in the API landscape as part of my API Specification Toolbox project which grew out of Postman becoming a member of the OpenAPI Initiative, and I wanted toht spend why Saturday afternoon (I know I have a problem) thinking about the API landscape at the 250K.  APIs.json API Property Types Using APIs.json or APIs.yaml you can define the properties of one or many APIs for a variety of purposes. Each API you describe can have an array of properties which can be common human readable elements like documentation or sign up, as well as machine readable properties like OpenAPI, AsyncAPI, or JSON Schema. APIs.json property types are intentionally human or machine readable with the intent on evolving every human readable element to have a machine readable element—think the relationship between documentation (Human) and OpenAPI (Machine) when understand the objective. I have several thousand API Providers and API service providers in my API Evangelist database. I track on the properties of all of these companies, organizations, institutions, and government agencies that I come across. When I group the property types across the thousands of APIs I have indexed, I end up with this default set of building blocks for API providers, grouped by different areas of the API lifecycle. Onboarding These are the properties of any API operation that help consumers, or any other party onboard with the concept of an API, begin using the API, as...[Read More]


API Evangelist

What Does Open Mean in the World of APIs?

11 Jan 2021

The word “open” gets thrown around so much in the API space I find myself needing to regularly ground myself in what it actually means. It gets thrown around in so many different ways that I find eventually I start to believe the bullshit and regularly have to pause and recalibrate. It is one of those words that has been captured and used by people looking to manipulate the space so often it often means the exact opposite of what we all think it means, but it is also such an important word that I think we have to fight to keep it in our vocabulary. I feel like I am perpetually fighting with some invisible force over one of the front doors to the house we all live in, and I am determined for the door to not get completely shut, and I have to make sure the door actually ends up go where someone expects when they do open the door. Let’s begin by actually taking inventory regarding the many different ways people use the word “open” to describe the world of APIs. Gathering all the ways it gets wielded in service of publishing and consuming APIs. Some of the ways in which it gets wielded are good, and some of them are bad. At this point I am just looking to be able to see the spectrum of use, and I am not looking to entirely pass judgement on anyone who uses it in specific ways. Here is the laundry list of ways “open” is wielded that impact the landscape I pay attention to on a daily basis, and have been helping shape for the last decade.   Publicly Available - Open means something is available to anyone in the public, allowing them to use an API, and any resources around them.  Access - An API or supporting resource is open for access by the public or the developer community in general, making...[Read More]


API Evangelist

Taking a Fresh Look at APIs Across All the United States Federal Agencies

27 Dec 2020

It has been a while since I looked at the 250K view of what is going on with APIs across federal government agencies in the United States. Since working for the Obama administration in 2013 I am perpetually on a quest to map out what is happening across federal agencies, helping drive the conversation forward. I belieive APIs can make the most impact when our federal government helps lead the way, and I am looking to help push things forward in the following ways. Keep mapping out the Federal Government API Landscape - I am determined to produce a map of the APIs that exist across federal agencies and keep the list alive and active. Establish Public API Workspaces for Federal Agencies - I am looking to establish public API workspaces for agencies who are implementing APIs--helping do some work from the outside-in. Refresh My Memory of What is Happening - I thrive on knowing what is going on across federal agencies, and doing these reviews pushes me to refresh my awarenss of APIs at this level. Fire Up new Conversations - These sotries always rise up in the SEO game and bring in new conversations with folks who are doing interesting things with APIs in government. I always learn a lot looking through the different government agencies. I learn even more wading through the different datasets, databases, and various incarnations of APIs. There is way too much work here than one person can handle, and much of what I come across labeled as an API really isn't an API, but could be with a little work. While doing these roundups I always reach a point where I feel like I am not doing enough, but ultimately I have to strike a balance between being comprehensive and just scratching the surface. Providing just enough information to allow me to plant seeds that might grow into new conversations down the road, while not spend all of...[Read More]


API Evangelist

A Postman Collection For Capitalizing Folders and Requests In Collections

17 Dec 2020

Sometimes I need to do bulk updates to Postman collections and there is no better way to automate this than to use a Postman Collection that uses the Postman API—inception level stuff, so be careful ;-). I have setup a dedicated public workspace where I am building out these utility type operational level collections that help me manage the API lifecycle out ahead of what the Postman GUI is capable of doing. Some of the things I am doing will eventually make its way to the Postman UI, but some of them will not. Either way, I am too impatient to wait, and one of the things I love about Postman is that I can hack my way forward through just about any situation using the Postman API. Building on my base collection for pulling and updating collections, I added two differents requests that will help me capitalize the first letter of each word in a folder or request name of a collection. Apply Title Case to All Folder Names in a Collection Apply Title Case to All Request Names in a Collection To run, all you have to do is make sure you’ve entered a collection ID (pulled from URL or info tab), and hit run—it will loop through each folder and request and capitalize the words, and then save the collection using the Postman API. So you can immediately put to use the same collection with the changes you desired. If you have any questions on the collection for pulling a collection and making changes using the Postman API, feel free to submit a comment for the collection as part of the collection workspace. I’ll be centralizing the evolution of this collection, as well as other collection related collections within this workspace. You can also fork the collection and use in your workspaces, and submit back any enhancements you’d like to see as a pull request. If you have any questions that you don’t...[Read More]


API Evangelist

APIs are at the Center of the Federal Trade Commission (FTC) Lawsuit Against Facebook

12 Dec 2020

The Federal Trade Commission is sueing Facebook, alleging that they are illegally maintaining a monopoly on the personal social network space using a continued series of anticompetitive behavior. The suit includes a coalition of attorneys general of 46 states, bringing the latest wave of regulatory scrutiny into the social media platform, highlighting three main dimensions of how Facebook has engaged in a systematic strategy of anticompetitive practices that has resulted in their current dominant position online. Instagram - Facebook purchased Instagram to remove what they saw as one of the biggest threats they faced, while also purchasing market dominance in the image and photos sharing space. WhatsApp - Fsacebook purchased WhatsApp to remove what they saw as one of the biggest threats they faced, while also purchasing market dominance in the messaging space. API - Facebook used their API to cut off access to applications they saw as a threat, and to generally suffocate anything else they saw as a threat to their business model. The anticompetitive nature of Facebook’s Instagram and WhatsApp purchase isn't really in my wheelhouse, but how the API was used for anticompetitive activity most definitely is my speciality. I am happy to see the FTC finally elevate the abuse that has been going on at Facebook via it’s APIs, not just because of the impact on the Facebook developer community, but more importantly the wider tech sector. Facebook’s approach hurts wider competition across the tech sector, but also hurts the space API sector--ultimately giving APIs a bad reputation. To help me speak intelligently to what is occurring as part of the FTC’s lawsuit, offer my advice on what a remedy might be, while also contributing to the future of regulation in the tech sector, I wanted to gather my thoughts in a post here on the blog.  Anticompetitive Conditioning Using The Facebook API The acquisition of Instagram and WhatsApp by Facebook to neutralize threats in two keys areas are a...[Read More]


API Evangelist

Gathering My Thoughts on Public API Workspaces

05 Dec 2020

I have been neck deep in the release of Postman public workspaces lately. So much so, I haven't had much time to gather my thoughts about what exactly they are, and why they matter. Time for a burst of storytelling to help me make sense of just what is a public APIi workspace. One of the most common responses I've heard from folks that I talk with about public workspaces is that they are most comparable to a public GitHub repository, but designed just for APIs. Fair enough. While I see Postman public workspaces as much more than a Github public repository, it provides a great place to start when it comes to helping folks understand the potential. To help me be more articulate when it comes to speaking about why public workspaces matter, let me compare them to public repositories, and speak of the impact that GitHub has had on my reality, as well as on the wider API community. GitHub Changed My Life I have been using Github since 2010, but beginning in 2014 I began operating a significant portion of my API operations via GitHub. I ran all of my public presence there from 2014 through 2020, and I still regularly use it as a base for many API projects, and for publishing JSON and YAML files. In the last year I have pulled back much of my web presence for API Evangelist back from Github, but I still depend on it for most of my projects for the following reasons.  Free - It is free to publish repos to Github, making it a pretty sweet place to publish APIs, schema, JSON, YAML, code, and other artifacts. Network - The network effect of Github is huge. Developers get it, and the access and discoverability that comes with the platform are worth it.  Social - The social layer GitHub added to Git is really what makes the platform as powerful as it is,...[Read More]


API Evangelist

Expanding the Vocabulary for Run in Postman Buttons

05 Dec 2020

I have long been fascinated by the Run in Postman Button. A Run in Postman button can be published from any Postman collection, organizing a single, or a series of API calls into collection of API requests, and then letting them be imported and ran locally by any consumer, as a cloud monitor, or via a pipeline. Run in Postman buttons are a common way for API providers to onboard new developers with their APIs, and stay engaged with active developers through collections they’ve download via Run in Postman buttons. These embeddable goodies attached to Postman collections and potentially environments are very powerful unit of API execution, but I am finding that the label “run” isn’t sufficient in articulating what is possible with each collection, and I a looking to get a little more precise when it comes to my vocabulary attached to each Postman button I publish. The Run in Postman Button Fundamentals A Postman collection is basically a portable folder of API requests. Using Postman, developers can define the parts of one of many API requests, including the URL, parameters, headers, body, and authentication, then roll them all up as a collection that can be shared with other developers, and published as documentation, as well as using a Run in Postman button. This embeddable HTML or markdown button can be published alongside documentation, or more dynamically as individual buttons on any HTML or markdown page, attaching each button to the following elements:  Collections - Each button can execute a single collection of one or many API requests, complete with pre-request and post-request scripts. Environments - Each button can possess a single environment that can contain a variety of key / value pairs for authentication, and other purposes. You can find Run in Postman buttons sprinkled across Twitter API documentation, providing one click import of collections into each developers own workspace, where they can manually run, or automate using a monitors, or trigger via...[Read More]


API Evangelist

A Postman Collection For Updating a Collection Host, Path, or Query Parameter

30 Nov 2020

Sometimes I need to do bulk updates to Postman collections and there is no better way to automate this than to use a Postman Collection that uses the Postman API—inception level stuff, so be careful ;-). I have setup a dedicated public workspace where I am building out these utility type operational level collections that help me manage the API lifecycle out ahead of what the Postman GUI is capable of doing. Some of the things I am doing will eventually make its way to the Postman UI, but some of them will not. Either way, I am too impatient to wait, and one of the things I love about Postman is that I can hack my way forward through just about any situation using the Postman API.  Building on my base collection for pulling and updating collections, I added five specific requests that will help me conduct a find and replace on each API request host, path, and the query parameter key, value, and description. There are other dimensions I am looking to cover with future requests, but this gets me what I need right now. You simply add a value to the request for a find and replace value, make sure you’ve entered a collection ID (pulled from URL or info tab), and hit run—it will conduct the appropriate find and replace, and then save the collection using the Postman API. So you can immediately put to use the same collection with the changes you desired. If you have any questions on the collection for pulling a collection and making changes using the Postman API, feel free to submit a comment for the collection as part of the collection workspace. I’ll be centralizing the evolution of this collection, as well as other collection related collections within this workspace. You can also fork the collection and use in your workspaces, and submit back any enhancements you’d like to see as a pull request. If...[Read More]


API Evangelist

Helping the Public Data Commons Drive Our Economy Using APIs

27 Nov 2020

What is an API? An API is a digital interface for sharing data, content, and algorithms with web, mobile, and device applications using the Internet, building on web technologies to make digital resources available across many different applications. APIs have been around since computers and their networks first gained a foothold back in the 1960s, but with the rise of the web since 2000, a new breed of APIs have emerged which has changed how we build and use technology, and introduced entirely new ways of doing business, but sadly, they have also introduced entirely new ways of exploiting an destabilizing the physical world around us. APIs aren’t the latest techno solutionism, although they are oftentimes billed as that, they are the digital currents that flow around us each day. APIs power the web and mobile applications we depend on each day, while also steadily working to redefine our physical worlds by connecting everything to the Internet—reshaping our virtual and physical worlds, while also remaking who we are as humans along the way. Websites Are for Humans The web as we know it has been evolving for over 50 years, but in the 1990s it became something we were able to access in our homes and businesses, laying the foundation for the ubiquitous web of applications we now access in our homes via laptops, televisions, and other appliances, as well as our cars, in our businesses, and across our communities in the form of security cameras, traffic infrastructure, digital signage and much more. Websites are hypertext markup language (HTML) that are designed to be rendered for humans in a browser, making the text, images, and other media consumable by humans using their eyes and ears, and navigated using our fingers via touch screens, keyboards, and increasingly voice controls. Websites provide us with a user interface that each person can put the web to use in their personal or professional worlds, connecting us with the digital...[Read More]


API Evangelist

Pulling the OpenAPI For Any API You Are Managing With Postman So That You Can Apply Across the API Lifecycle

23 Nov 2020

I am using Postman to do more governance on my OpenAPI definitions as part of their API lifecycle. This is a top request of customers I am talking to, so I want to get better at make these individual API lifecycle capabilities much more modular and reusable as Postman collections. In Postman, the OpenAPI is the truth for each API contract throughout the API lifecycle, but each collection has become how you automate each stop along the API lifecycle. Resulting in me needing the OpenAPI for each API I am automating, and being able to pull the OpenAPI truth using the Postman API within each collection I am defining to mock, document, test, and govern each API. You can find a single collection for pulling the OpenAPI for an API from the Postman API using it’s name (boy that is a mouthful). The collection is designed to abstract away three separate API calls into a single request. Ideally Postman will provide a similar API endpoint, but until that happens I have this collection to help make things easier. The documentation for the collection should provide you with everything you need to get up and running with the collection, pulling the API into a Postman environment for reuse. It is up to you to decide what you will do with the OpenAPI after that, possibly making multiple changes, and then saving back to Postman using the API. If you have any questions on the collection for pulling the OpenAPI as part of the API lifecycle, feel free to submit a comment for the collection as part of the OpenAPI workspace. I’ll be centralizing the evolution of this collection, as well as other OpenAPI related collections within this workspace. You can also fork the collection and use in your workspaces, and submit back any enhancements you’d like to see as a pull request. If you have any questions that you don’t want to see in the comments...[Read More]


API Evangelist

Automating the Management of Postman Collections Using a Postman Collection

23 Nov 2020

I am managing more collections via hundreds of different workspaces lately. As part of my work I am needing to make bulk changes to collections based upon a variety of properties. Sometimes I need to find and replace variables, and other times I need to rewrite or append to the descriptions for each collection. Whil I am sure eventually there will be capabilities to do some of this via the Postman interface, I find creating maintenance collections that use the Postman API to do what I need is the quickest way to get what I want, without having to wait for the Postman road map to catch up to my work. I have a whole list of automated changes I want to make to Postman collections that I am generating from OpenAPI definitions, and to help me quickly work through this list I wanted to create a base collection that I could use to augment with common and some unique scripts for making changes to any collection, and then save the results back using the Postman API. You can find this collection in my public workspace for managing my collection work, where you can fork it and apply to the changes you need to make to collections. You are also welcome to just wait until I get specialized collections built, or feel free to submit a suggestion for a variation that maybe I haven’t considered. If you have any questions on the collection for pulling a collection and making changes using the Postman API, feel free to submit a comment for the collection as part of the collection workspace. I’ll be centralizing the evolution of this collection, as well as other collection related collections within this workspace. You can also fork the collection and use in your workspaces, and submit back any enhancements you’d like to see as a pull request. If you have any questions that you don’t want to see in the comments...[Read More]


API Evangelist

A High Level Look At API Specifications

23 Nov 2020

I am having an increasing number of conversations around how the leading API specifications work together, and what the role of each are when it comes to various stops along the API lifecycle. To help drive conversations I wanted to create a single blog post I can link to, while also loading up all of my fresh thoughts about API specs into my old brain. All of these API specifications are continuing to see massive adoption across API providers and consumers, and they are all in forward motion being iterated upon by the specification owners, so it helps to pause once or twice a year and take a look at what is going on, and work to understand how all of these API specifications work together (or don’t). What Are The Leading API Specifications There are a handful of API specifications that are relevant to delivering APIs in 2020, helping provide a vocabulary for stakeholders in the process to use when describing what each API does, so that a common definition can be applied through the API lifecycle, consistently delivering API infrasture across many teams. Here are the API specifications I am focusing on as part of my API Specification Toolbox conversations. OpenAPI - A specification for defining the surface area of HTTP 1.1 web APIs using JSON or YAML. AsyncAPI - A specification for defining the surface area of HTTP 1.1, HTTP/2, HTTP/3, TCP, MQTT, and AMQP APIs using JSON or YAML. JSON Schema - A specification for defining the underlying models in use for APIs, adopted by both OpenAPI and AsyncAPI. Postman Collections - A specification for defining executable collections of HTTP 1.1 web APIs for running in services and tooling Postman Environments - A specification for defining key / value pairs that get applied across collections at execute time. RAML - A YAML format for describing the surface area of your HTTP 1.1 APIs, and the the underlying objects. GraphQL - A query...[Read More]


API Evangelist

Managing the Scope of Your OpenAPI

18 Nov 2020

Managing the size of an OpenAPI is a common challenge for API development teams. I have regular conversations with teams about the ways in which you can minimize the overall scope of an API, breaking things down into more manageable chunks, while also reducing redundancy—then encouraging reuse. Like other dimensions of the API space there are differing opinions on whether it is better to have one single OpenAPI for all of your APIs, or whether it makes more sense to break things down into well defined bounded contexts. You can see this debate occurring in Monolith vs Microservices, and MonoRepo vs Multi-Repo discussions across the API space. In this game, there are no right or wrong answers, just different approaches that work well for different organizations, teams, and individuals. My goal is to help folks understand the trade-offs by informing them enough to make their own decisions and set into motion API design practices that keep the API factory floor moving along. The size of your APIs matter. The size of your OpenAPI for your APIs matters. The scope, complexity, and consistency of your APIs will define how easy they are to maintain and put to work. Organizations that do not use OpenAPI struggle with being able to define the API landscape at all, let alone being able to define the scope of individual APIs or groups of APIs. It is common for API providers who are moving into the OpenAPI realm to slam into the brick wall of API scope right away, realizing their OpenAPI definitions are too big to work with in some services and tooling, and become a maze of complexity when it comes to maintenance and consumption. While there are many ways your API design practices can reduce or at least better define the scope of your APIs and resulting APIs, there are a handful of ways you can slice and dice your APIs up to make them easier to manage,...[Read More]


API Evangelist

Using API Mocks as Part of an API-First Workflow

17 Nov 2020

I owe an answer on my thoughts about mocking APIs to my coworker Andy, and I don’t want to incur his wrath, so I figured I’d write it up and share wider as I was getting back to him. I don’t have the original question cause it was in a Zoom chat, but it was something to the effect of using mock APIs to move forward the design of an API versus using them to drive application development conversations as well as push testing forward. I’d say that using a mock as part of an API-first design process reflects where I am pushing mocks to work for me more often. I still use them to demo, prototype applications, and as part of API testing, but using them to actually evolve the contract for an API is really where I feel that a mock server will really shine, and can shift how we are delivering APIs. However, there is also a lot of education and awareness needed before I get all the folks I am having conversations with on board with this concept—to help in these efforts I wanted to flesh out a little about what I mean when it comes to API-first usage of mock APIs. Mocking From Postman Collections The first part of this conversation involves the concept that you can generate a mock server from any Postman collection. There is a three step process involved with producing a mock API in Postman using a collection. First you create a collection with the path and parameters you would like to use as the definition of the API you are mocking. Once you have your path you can select examples up near the send button and add a new example for this request. It will take your path with parameters and map to a new example where you can add a JSON example to represent what should be returned by your mock server for an example....[Read More]


API Evangelist

The Multiple Dimensions of API Deployment

17 Nov 2020

API deployment is the OG stop along the API lifecycle, but is still the most underserved when it comes to API service providers providing solutions, and as part of the full lifecycle API management conversation. I remember back in 2011 folks asking me which of the API management providers would help them deploy their APIs, which at the time none of them would, being a pretty regular concern when it came to doing APIs at all, let alone doing them well. I have seen many “API deployment” solutions come and go, and after a decade I see some movements forward, but overall API deployment is still really difficult in ways that just doesn't make sense. Data APIs Making data available via simple APIs is the most common type of APIs you will come across out there, and the most common reason for providing as well as consuming APIs. Deploying data APIs are pretty straightforward to do, and there have been a wide variety of services and tooling made available to help developers deliver these types of APIs. Even with the simplicity of this type of APIs, I haven’t seen too many platform successfully monetize a data API deployment solution, or deliver a dead simple, widely adopted, single push of a button solution to delivering data APIs. It really is one of those areas that should have been 100% solved by now, and would be if it was for the incentive models that exists behind most platforms, but also due to some pretty widespread unhealthy practices when it comes to managing and publishing data, making a lot of data pretty messy to work with when it comes to making available data APIs. Content APIs These types of APIs often overlap with the world of data APIs, but I want to highlight them separately because of content delivery network (CDN) considerations, as well as movements in the headless CMS world when it comes to enabling dead simple...[Read More]


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]