Postman 3.0 Releases New Developer Experience - Q&A with Founder

Postman is a popular Chrome application used to test, build, and document web APIs. The Chrome web store rates it as 4.6 stars based on close to a thousand reviews and indicates that one million developers use it.

InfoQ interviewed Abhinav Asthana, the founder and CEO of Postman, about the latest release to give our readers a better understanding of what Postman is, how it was created, why it’s popular with API developers, and what’s new in 3.0.

InfoQ: Can you describe the story behind Postman’s creation and how it has evolved?

Abhinav Asthana: Postman started off as a simple side project. I had been working with APIs since early 2010. I was at Yahoo as an intern with my co-founder, Ankit, who had just joined as an employee. We were working on a front end for a service that managed data for Yahoo properties through an API.

I was not very happy with the tools that were available for testing APIs then; curl commands were scary and there was a lot of back and forth between us and the API developers about how the API works. This was a rapidly changing API and mistakes were quite frequent. After my Yahoo experience, I started another company where I worked on the front end as well as the back end. When our team started expanding, we faced problems such as sharing API documentation and testing APIs. I started looking for existing tools to make our lives easier but did not like anything in particular.

The key feature in the first version of Postman was the request history that let you go back in time and replay a request. Postman Collections came in soon later. Since then, Postman has grown through word of mouth with great support from the developer community. The feedback was very strong. Ankit and I then got together to add authentication features like Basic Auth, OAuth 1.0. The use cases that Postman solved kept exploding even without us knowing it. We were amazed by the response and then started looking deeper into the underlying problems with API development and that led to the founding of the company when Abhijit joined us in August 2014.

InfoQ: What is your vision for Postman?

AA: Postman is aiming to make developers, teams, and companies faster through every step of an API’s lifecycle. We noticed that there is a ton of repetition in the way APIs are developed, consumed and distributed. Testing is often an afterthought. Documentation is usually left at the end. And there are a lot of problems that teams don’t even know about!

While some of this can be mitigated by adopting certain processes, we believe that’s not enough. Developers need better tools. Products for developers have often focused on just utility and not enough on the developer experience. With the number of APIs exploding the developer experience is going to be a critical component of how APIs are created and consumed.

InfoQ: How do the various components of Postman platform and how do they all fit together?

AA: The following components are part of the Postman ecosystem:

1. Postman Chrome app: The Postman Chrome app is at the core of the whole ecosystem. Postman on Chrome lets you send requests, analyze responses, organize requests in collections, write tests and a lot more. This is usually the starting point for most developers.
2. Postman Collections: Postman Collections is our metadata format for describing a group of requests. It’s very liberal in what it can consist of. It can be used for documentation or API scenarios. Collections can be downloaded as JSON files and used anywhere needed.
3. Newman: Newman is Postman’s command line companion based on node.js. It let’s you take Collections outside of Postman and run them through the command line. Newman works on all platforms. Newman can be used for build system integration or just calling APIs at regular intervals. Being a command line tool helps it to be integrated with almost any system out there.
4. Interceptor and Proxy: These are two tools that we provide to help developers capture requests in production environments without touching code. The Interceptor can stream in requests from Chrome into Postman’s history and then analyse them or organize them. Postman Proxy can do the same thing for desktop apps or mobile apps. We are still working on improving support for these. Interceptor also has one other use case. It establishes a bridge between Postman and Chrome so that Postman can use Chrome’s cookies.
5. Postman Sync: This is our latest offering that has been in private beta for a while. Postman Sync helps teams collaborate around API development. Collections can be shared within a team. Changes are shared in real-time. Everything inside Postman is backed up automatically and can be shared with team members with proper access controls. We have a free tier that backs up data for individual developers for free. With Postman Sync, teams can tie together all of their API development systems - through Postman’s tools or other tools.

All of Postman’s tools aim to smoothen out friction with different aspects of API development. Collections is the unifying entity while Postman Sync is the service that literally aims to keep everyone on one page.

InfoQ: You recently launched the version 3 of Postman in beta, three months after releasing version 2. What are the major changes and when do you plan to have it generally available?

AA: Version 2 marked the release of Postman Sync for individual developers. Version 3 was oriented towards rethinking some aspects of the developer experience while keeping in mind future additions to the toolchain.

Some notable features in version 3 are:

1. New user interface with a new design language.
2. Collection Browser that lets you view documentation within Postman.
3. Tabs to let you browse multiple requests.
4. Code generator
5. Better search features
6. Postman Sync available for free for everyone.

Version 3 will act as a base for some amazing features that we are building. Version 3 will be available to everyone starting this week.

InfoQ: Based on your experience with the Postman community, what are the main API development workflows that you observe today, how are they evolving, and which do you recommend?

AA: There is a lot of variation in what different teams end up adopting as their workflow. Considering the vast scope of what APIs do, it’s tough to come up with a workflow that fits everyone. We see a lot of variables in API development, some of which are:

1. API functionality - what an API aims to do, how critical the functionality is, how often it is used.
2. API size - Number of endpoints in the system? How big is the API?
3. Infrastructure - how internal systems are organized in the company. Are there existing practices or architectures that are in place?
4. API consumption - Is it just backend developers or we have frontend developers too? Do we have separate QA developers. Is the API publicly available or is it just for internal use?

Developers generally pick a workflow that roughly fits across all these variables. This of course leads to problems when the API evolves. For example, teams might skip on documentation assuming that this is just going to be used by internal developers.

The most common workflow that we see starts off with an API coming into existence in code. It’s given to API consumers and then more parts like documentation and testing are filled in. API design tools are adopted in some places though not all.

We don’t mandate a specific workflow but do hope that our tools will nudge developers towards ticking off checkboxes that would lead to a good API that is tested, documented and performs well. This helps us reach out to a wide variety of teams and get them to adopt Postman the way they like it instead of forcing a system on top of them.

InfoQ: Earlier in June, you announced version 2 of the Postman Collections format. Can you explain what changed and why it is important for API developers?

AA:

Postman’s current Collection format was an accidental discovery. It was the internal format in which Postman stored groups of requests. It organically evolved into a format as more and more developers started using Collections in their toolchain. Developers would just export a collection and start plugging them into things or even start generating collections.

While working on some newer features for Postman, we discovered that this was not the most ideal way to go about it. We took a step back and started looking at the entire API workflow around Collections. We looked at use cases that developers use Postman for and the use cases that we could enable. Taking into account all of this, we have published a draft of the v2 format. It’s still under active development and we would encourage the community to give feedback.

We believe Postman Collections are going to be a key part of the API economy and we want to have a solid base which developers can build upon.

InfoQ:How does the Postman Collections format compare to API description languages like API Blueprint, RAML, and Swagger?

AA: API description languages are quite different from Postman Collections though there is some overlap. A Postman Collection can be used as a source-of-truth if an API already exists. Or it can be used as a sequence of API calls mapping out a use case scenario. Collections can be used as a program itself - just executing a use case using our Collection Runner or newman for example.

There is no restriction on what a Collection can be. Our goal is to help developers solve their API workflow issues with Collections without insisting that they document their APIs first. This free flowing nature of Collections helps developers be more productive.

Another key difference is that Postman Collections can contain JavaScript code. API endpoints inside Collections can be self-testing if testing code has been added. This gives a lot of power to developers in getting things done. We aim to make Collections interoperable with other formats. We already have importers for the most popular formats and are working on adding more.

InfoQ: There has been some interest again for the HAR format (HTTP Archive) based on Kin Lane’s blog post. How do you see Postman Collections fitting in the overall API value chain?

AA: We have been exploring HAR for a while. Chrome allows you to download network requests in the HAR format and some of our users had requested the ability to import HAR data. In the context of products that are browser-based this makes sense as the data is already available as HAR. We haven’t seen developers generate HAR archives yet.

Postman Collections do let you save responses along with a request and we have seen our users create collections automatically in their backends. They then bring these collections back into Postman for debugging. It’s an interesting use case and we will definitely explore this more. We are excited about the possibility of combining actual production data with the design specification and see what worked and what did not.

InfoQ: When using Postman, some sensitive data are being manipulated such as logins, passwords, and tokens. Should API developers have concerns about those security aspects and do you address them from a product point of view?

AA: Definitely. API security should be the top priority for developers. APIs wield a lot of power and if security is not accounted for, it can have disastrous consequences. Sharing API meta-data and sample calls can expose tokens and passwords inadvertently.

We address these issues inside Postman by keeping them separate through the use of environment and global variables. If you have any sensitive data inside an API call, you can create a variable for it. The value of the variable is stored inside environments/globals and Postman does the substitution when the request is run. This enables developers to share a Collection without worrying about exposing anything that they would not want.

For our Sync service, we encrypt environment variables on the server side. We will soon offer support for client-side encryption using a passphrase so that these values are encrypted even during transit. Of course, all communication between our servers and the Postman app happens through secure channels.

InfoQ: Postman started as a Chrome extension and is now packaged as a Chrome app. Can you explain why you made this transition and what is your view on the evolution of the development environment for Chrome?

AA: Postman started out as an in-browser app on the now legacy Chrome app platform. To make the Chrome app experience closer to native apps, Google released the new Chrome app platform with better sandboxing and more APIs. This made a lot of sense for Postman and enabled us to develop the testing suite without much effort. Along with that, we could still maintain a link with the browser due to in-browser messaging systems.

We wanted to make this shift so that we don’t have to deal with last-minute platform issues in case Chrome decides to deprecate the existing platform completely. This, I believe, was a good decision as Chrome stopped letting users upload new legacy apps a little later. We still push updates and bug fixes to the legacy app but the goal is to migrate everyone to the new app.

The Chrome app ecosystem has been one of the key drivers for Postman’s growth. We were able to reach users across all operating systems while still using one language. We were also able to maintain close ties to the browsers and have access to Chrome DevTools to complement Postman’s functionality. That said, Chrome apps still need a few more APIs to be on par with native apps. The on-boarding experience for new users and window management is still an issue. We are optimistic that the platform will keep evolving quickly.

InfoQ: Are you planning to distribute Postman in other browsers or desktop environments in the future?

AA: We are exploring these options very seriously. We have some great ideas planned and a native desktop environment would help us execute them better. We will announce something on this front soon.

Disclaimer: the author of this article works for Restlet, a web API platform provider supporting several testing tools including Postman.