I was profiling the Atlassian APIs, considering what is possible with JIRA, Confluence, and Bitbucket. Three services that are baked into many enterprise organizations I’ve worked with over the years. My intention was to create a Postman collection for JIRA, but once I Landed on the home page for the API I noticed they had a button in the top corner for Running in Postman, and a dropdown for getting an OpenAPI 3.0 spec. Which is something that I strongly believe should be default for all APIs, ensuring there is a prominently placed link to the machine readable truth behind each API.
I like seeing Postman as the default executable in the top corner of the documentation for APIs. I also enjoy seeing the orange Run in Postman button across documentation, blog posts, and other resources—helping folks quickly on-board with some API resource or capabilities. I want to see more of this. I’d like it all to become the default mode of operating for API providers. I want all API providers to manage an OpenAPI truth for their API, while also developing and evolving many different Postman derivatives of that truth. Providing reference collections that describe the full surface area of our APIs, but also make sure there are more on-boarding, workflow, and capability style APIs that empower end-users to put APIs to work distributed across API documentation, and the stories we tell about what is possible with our APIs.
Interestingly the Postman collection isn’t just a unit of representation for the JIRA, Confluence, and BitBucket APIs. The Postman collection is also a representing of the unit of work that is executed across these platforms. If you have worked in software development across the enterprise you know what I am talking about. Postman is the Swiss Army Knife for how enterprise developers not only develop and deliver their work, which is defined and tracked using JIRA, Confluence, and BitBucket, but Postman collections are also how they articulate, quantify, and demo their work as part of the JIRA-driven software development lifecycle. 75% of the companies I’ve worked for, and consulted with over the last five years are using JIra to orchestrated the development of APIs and the applications they drive. At these companies Postman is ubiquitous, and how developers quantify each unit of work they are response for, making it critical to not just how Atlassian does business, but also how all of Atlassian’s customers do business.
A Postman collection is a representation of a unit of work within the enterprise, which once complete will represent a unit of organizational capability. Each individual API defined using Postman represents a part of the digital transformation that is occurring across every enterprise organization. Postman is how developers are defining and delivering their work, and how they are sharing, collaborating, demonstrating, and ultimately executing the result of their work. When you think of the scale of this based upon JIRA usage world wide across the enterprise, it can be pretty staggering. Trillions of units of work. Millions of Postman collections. Millions of Postman users. Trillions of individual digital capabilities being defined, delivered, monitored, executed, tested, and reported on each week. Making the digital factory floor work across companies, organizations, institutions, and government agency work each day.
