As I work my way through the features of Postman and work to bring it all into alignment with my existing storytelling around APIs, one of the areas I’ve been slowly adding to my collective API research is "collaboration". I setup collaboration.apievangelist.com a while back to help track on what different companies are up to, as I do with any other area of the API landscape. Collaboration is a pretty big tent to operate within, with many different interpretations of what it means, and a growing number of examples out there regarding how it can be done. While there are many features of Postman that get me excited, I’d say the collaboration features around Postman collections, workspaces, and the API development platform is what I wold call the next killer feature—let me explain a little more about why.
One of the things that attracted me to the potential of APIs back in 2010 when I first started doing this, was the way APIs brought me out of my shell. As a database administrator I had grown accustom to be siloed. Just leave me alone. Let me do what I do. Keep those business people at a distance. The only problem with this reality was I kept getting further and further away from the business problems I was working to solve, which resulted in some pretty catastrophic mistakes. Then I made the mistake of deciding to take management route with my career, which then resulted in the opposite problem—I was too close to the business problems, and too far away from the technical solutions. I wasn’t coding anymore. I couldn’t deliver the solutions I was needing. I realized that I needed a bridge between business and development, and APIs seemed like the solution to me.
APIs force us out of our bubbles. It forces us to integrate with other internal groups, partners, or public users. The killer feature of APIs is interoperability, allowing us to have a conversation about the resources we are making available. When done well, it forces us to establish feedback loops between provider and consumer, and ideally between IT and business unites. APIs are about collaboration, so it makes sense that the API lifecycle should be about collaboration and working together, throughout the entire API lifecycle. 95% of the API challenges we face are human problems, not technical ones, making collaboration the grease in the API gears. Any API service providers that invest in collaboration, syncing, sharing, workspaces, and other human enablement solutions alongside their primary, will do well in this climate of exponential API creation and adoption.
APIs aren’t meant to be consumed in silos, and they shouldn't be developed in silos. The API lifecycle needs collaboration at every stop along the way, and seamlessly with the many different tools that might be in use by developers. This is why API definition formats like OpenAPI and Postman collections have made such an impact. You can import and export these API definitions into almost every modern API service or tool out there, the product is that most people are still sharing API definitions via email, chat, or hopefully at least Git. As API architects, designers, developers, and evangelists, we do not have a lot of solutions that help us not just maintain the API definitions, but also to reduce friction throughout their lifecycle. This will make any features that enable seamless, effortless, frictionless collaboration something that will make a big impact on how we get business done in the next wave of API expansion--ising up to be more of a killer feature than any direct API functionality I can think of currently.
