I am now immersed in all things Postman. After a week at Postman, attending POSTCON, and listening to how API developers are putting the API development environment, I have realized what a Swiss army knife the platform is. I get the core functionality of the application very well, and have used for several years. However, I only lightly understood the mocking, testing, monitors, runners, documentation, and other key features. I also was introduced to how pre and post scripts reduce friction, and the versatility, portability, and share-ability of Postman Collections. I’m beyond ecstatic to be studying and evangelizing all things Postman, and get to spend full time thinking deeply about how it can be applied across the API lifecycle.
My days will be filled with me playing around with Postman, and defining, mocking, testing, monitoring, documenting, and moving APIs forward, then telling the story of what I am doing here on API Evangelist, on the Postman Blog, and as part of other conversations I’m engaged in. While this will keep me very busy, I’d like to hear what you are doing with Postman. I want it all. I want your mundane stories about how you use it just to make simple API requests. I want to hear the stories about why you aren’t using some of the other features like mocking and testing. I also want to hear all about the amazing lifecycle workflows you’ve cobbled together using Postman. After talking with companies at POSTCON I’ve come to realize how much Postman enables many of the common API lifecycle workflows we hear about, but also that there is a long tail of workflows that are cobbled together to meet the specific needs of teams on the ground—lighting my imagination when it comes to what is possible with Postman.
I am happy to showcase what you are working on here on the blog, as well as anonymize your story—it is something I do all the time. It’s up to you. I’m just looking to learn more about what is going on in the trenches when it comes to Postman usage within the enterprise. I knew that Postman is being used across the enterprise. I’ve seen it become the ubiquitous API client for enterprise developers over the last five years. I have also seen the Postman Collections quickly become a useful definition for describing API capabilities in not just a machine readable format, but when combined with environments, become portable, shareable, executable units of API value. I knew Postman was doing interesting things with mocking, monitoring, testing, and documentation, but hadn’t ever really played with an of it in a meaningful way. However, I had not idea of the impact that scripts and runners were having on how developers automated and orchestrated their API operations. I want to know more. I’d like to have a more robust set of stories to tell when it comes to this type of API lifecycle realization.
Feel free to email me at [email protected], or tweet at me via @apievangelist. Or better yet, publish a blog post about it and shoot the link over to me. I’m guessing y’all are doing some pretty interesting things with Postman that I’m not aware of. What I like best about what I’ve seen so far is that it is all very organic, and developer defined. The Postman client defines a lot for developers, but it really leans on HTTP requests and responses in conjunction with some pre and post request scripts for its magic. It is something that seems to speak to developers, and allows for an unlimited ways to approach developing, delivering, and consuming APIs. Anyways, share your stories with me. My inbox is open. Ping me with as much detail about your approach as you can, and I’ll add to my notebook, and see where I can riff off of what you are cooking up. I look forward to shining a light on your work.
