During one of our five or six hot days this summer, I jumped off the Muni line to visit a new office in San Francisco. On this particular evening, I was heading out to meet the people that unknowingly helped me learn how to build and interact with modern web APIs (or application programming interfaces). These people helped me by way of a free product called Postman that I found a year prior in a Google search. After walking a block and popping my head out of the elevator, I walked into a bustling startup office filled with visiting developers eager to see what new features their beloved product has in store. The meetup included an evening of enlightening demos and saw a glimpse at the latest Postman release. In this article, I share my interview with Abhinav Asthana, the CEO and creator of Postman, a wildly popular API development, documentation, and testing product. We talk about the humble beginnings of this fast-growing product and some late-breaking new features in Postman. The article edits the interview for brevity, but you can hear our entire talk by clicking the link below. And you can check out Postman here.
[soundcloud url=”https://api.soundcloud.com/tracks/335675081?secret_token=s-Smpek” params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]
Bill Raymond: What is the simplest definition for an API?
Abhinav Asthana: Fundamentally, an API helps you connect with other pieces of software that may or may not be on your computer.
BR: What is the history of Postman?
AA: Postman started as a side project in 2012. As a developer, I could not find a product that made it easy to make API calls to send and receive data. Debugging APIs was hard, so I hacked together Postman. I learned that you could offer your app on the Google Chrome store, so I put it up there and was surprised by the reaction from the development community.
Not too long after I put the app up on the Chrome store, people on Stack Overflow and Reddit started recommending Postman. One of the big indicators I had something was when Google contacted me because they use the product all the time and they wanted me to make some updates so they could put Postman up as a featured product on an updated Chrome app store platform.
We started getting a lot of investor interest, so we decided to create a company around this [the API market]. We started out as a company in 2014. We have such love for this product and had to be here in the heart of tech, so I moved to San Francisco in January of this year. Now, in 2017, we have over 4 million users and 2 million active monthly users. The Postman app is no longer a simple web-based tool, but a cross-platform desktop tool.
BR: What are the products you offer?
AA: We have Postman, which is a [free] desktop app with features like developing, monitoring, and mocking [more on that later]. We have Postman Pro, which is a collaboration platform, and we have Postman enterprise that has additional features like single sign-on, better support, and different billing options.
With Postman, you can start building the APIs as you are just thinking about them, build them, and then push them to production. You can also document your API even if it is not fully developed. You can build out tests for your APIs and integrate them with your CI/CD (continuous integration and continuous development) systems. You can also monitor your APIs in Postman.
Basically, Postman is designed for the entire lifecycle of designing, building, testing, and monitoring your APIs. It works very well for a single developer or teams collaborating on building their APIs.
We are making API development so easy anyone can use Postman. Let’s say you are a startup. At first, you have a back and developer and a frontend developer in a small team who are consuming and producing APIs. As the startup grows, they have more developers, and they want to offload some of the development and testing to QA and DevOps. Now you have a larger team testing and monitoring the APIs thoroughly.
BR: How many people use Postman, and what makes up your user base?
AA: We have more than 4 million users. Our users run the spectrum of frontend developers, backend developers, QA developers, DevOps. In some cases, people are consuming APIs, and others are producing APIs. We also have an open source command-line tool that has about 10,000 downloads a day.
BR: Developers use Postman, but they also use an IDE [integrated development environment] to develop code. How does Postman fit into the IDE story?
AA: We see APIs as a fundamental unit of development that has their own set of requirements. You need to test them differently and monitor them differently. There are certainly integrations with IDEs. You can export the metadata for your API and open it in your IDE. As your organization grows with more projects and more systems, the source of the truth lives in Postman.
BR: Businesses often need to integrate one application with another. How does Postman work in those scenarios?
AA: Let’s say you want to integrate multiple systems. You need APIs to do this. Very often, developers want to integrate with legacy systems. They may not have access to the code base for every application.
Let’s use integrating a marketing automation product with a sales automation product. You might need to map the ID of a user in one system to the ID of another system. You will need to know about the data model for each system. The reason many integrations do not work is the lack of documentation.
Another element is the data transformation and integration automation. That is why we invested heavily in providing a JavaScript platform that allows you to do the transformation and integration of data from one system to another.
As the data model changes, you want to verify your system still works, so you can script the whole thing and then run tests. You can also run these processes with Postman or our open source command-line tools. We even designed monitoring tools so you can see potential issues with your APIs.
Postman uses the JavaScript language for scripting, but we provide some wrappers to make it easier to work with APIs. For example, with SOAP services, you get a lot of XML out, so you can easily transform data to JavaScript libraries.
We also have an open source command-line tool called Newman to test API integrations. So if you want to transfer data from one API to another, you can just run the script a few thousand times to test the functionality.
BR: There are companies trying to make APIs more accessible, like Microsoft Flow, Zapier, and IFTTT. Where does Postman fit in this landscape?
AA: When you think about integrating disparate products with APIs, there are broadly two categories:
- There are API-management vendors with software like Microsoft Flow and the other products you mentioned.
- The other category is integration providers. These are companies you hire to do more advanced systems integrations.
Postman complements API management and integrations. We look at the developer workflow, not just providing gateways and proxies. We offer solutions for those companies as well. For example, we have complementary solutions for Microsoft Flow and AWS (Amazon Web Services) API Gateway.
Our goal is to make the process of building and documenting APIs super easy.
BR: You just announced a new Postman feature called mock server. What is that?
AA: API design to production should be super easy, all in Postman. A mock server can become an entity that anyone can work on without being tightly coupled with other systems. With a mock server, you can design, test, integrate, and monitor an API. A front-end developer can build the UI. A QA person can build their test cases. Mock servers are especially useful when building hundreds of APIs. The mock server is like a real API.
BR: How do you keep the mock server up to date?
AA: Typically the mock server is the one to be cut off from the development process. Now, mock APIs become a core part of the API development process. We offer the ability to document your API. As you update your API in Postman, you can use our publishing service to push documentation out to a website. One of our customers, Imgur, publishes their API documentation from Postman to their public website.
We envision the process of building testing, monitoring, and publishing an API to be super easy. A mock server can become an entity where everybody can work on it without being tightly coupled with other [systems]. Think of it as a real API, but without the complexities of running them in production.
You can give a mock server to the frontend developer to build user interfaces. You can give the mock to QA so they can build their scripts, and pass that on to other developer and DevOps team members. Mock server especially helps where you have thousands of APIs so that you can operate teams in parallel. The APIs become a living entity that is the source of truth for your APIs.
When you use a mock server, it acts like a real API, and you can predictably build your code against it. Demonstrating it is a little hard because it is all embedded, so when you save the API, it automatically becomes a mock server.
BR: You keep talking about documenting APIs. Documentation is typically left to the end, and it rarely gets done or done right. How do you get your APIs to a point where they are well documented?
AA: The problem is documenting an API in such a way it is understandable by people. You don’t just take a bunch of metadata and functions and expect that to be the documentation. Documentation should be a core part of the API, so we created a documentation tool within Postman. Coming to the end of a project and realizing you need documentation does not need to happen. If you continuously iterate and enrich the documentation and make it better, that is the best process. For example, the API needs to give sample code to get you started and give you examples to solve a particular pain point.
BR: Thank you for your time.
AA: Yes, that was a great conversation.
