Postman is an incredible service for endpoints testing. And it has some amazing features that only few people know. Let’s unleash the power with Postman!
Postman is a free SaaS for endpoint and API testing; created and developed in 2012 by Postdot Technologies, it’s use grown exponentially since then. It surged as a Chrome extension and in 2014 the native apps were released — for Windows, Linux and Mac. Today, more than 5 million devs around the world use the service.
In addition to the free endpoint testing service, today Postman has great solutions for API monitoring and mock servers creation — but some of these services are charged by API calls!
Here you can see the Postman’s solutions complete list
With all that huge growth, Postman can no longer be considered just another Saas which makes GET/POST requests to your endpoints. Today it is a powerful ally for us!
Many Postman’s features merge themselves. I’ll talk about some features I’ve been using on my development process, and I hope you use them too!
1 — API Requests
Postman’s main feature and basic goal. You insert the endpoint, select the HTTP method, add auth, header and body params and hit send button.
You can also set cookies, set a global proxy for all the requests and create local listeners, a proxy intented only for a port on your localhost.
In addition, you can generate code snippets of your request! Postman supports more than 20 languages/frameworks to export the code snippet from your request. You can find all supported languages here.
2 — Environments
Similar to Docker with its containers, in Postman you can create several separated environments with its own settings. Within these environments you can define variables, scripts and test suites that will run alongside your requests.
For example, you cand create an environment with your local development settings, another environment with homologation settings and another one with production settings. This makes everything much easier — you don’t need to hunt the parameters of each environment.
3 — Collections
This is an old and very well known feature, but it’s worth talking about. By definition, a collection is an organized group of individual requests. Put simply, imagine you have the route
/user/ in your app. You create a collection to group all the requests that point to this path.
This way, you centralize and organize all the required info for each request. Just like environments, inside your collections you cand define variables and go beyond — create test suites for each request, scripts and even workflows to simulate a real scenario, like if someone is using your app.
4 — Collection Runner
Collection runners work as a series of automated unit tests for each request of a collection. You can define the order each request will be executed, pass context variables and even switch between different environments.
You can also set how many times a request will be executed, debug it the test doesn’t pass and also persist variables between requests.
Collection runners also have integrations with Jenkins and Travis CI! To do it, you can use Newman, the CLI version of Postman’s collection runners.
5 — Scripts
With Postman’s scripts you can add dynamic behaviors to your requests — you can write a script that will run before the request execution and also write tests that will run after the request has finished.
6 — Mock Servers
Teams working in parallel is way much better than teams working with dependency. However, to build the code at the view layer you need to have an idea of what endpoints will look like and how the response will be sent by the server.
In this moment mock server enters — where you can simulate the back-end by creating mockups without necessairly having the “official” back-end code. With it, both teams (front/view + back-end) can work in parallel.
As the other features, you can define context variables, environments and even CORS configuration with mock servers.
But, imagine a situation — you, front-end dev, created a mock server and made all the code to handle the request’s response. However, the back-end dev didn’t use the same pattern and everything turned out differently (or vice versa). In addition to generating friction between the teams, it will generate rework and also will impact on the project deadline — everyone is wasting time!
To create a fluid integration between the areas, it’s very important to use code standards — the White House Web API Standards is a prime example of it. And it’s also important to make a deal across the teams to avoid generating rework.
But, that’s a subject for another text!
7 — Monitors
Postman Monitors allows you to execute a collection in a certain time to find out the status of your API.
You can use this feature as an automation allied to collection runners — the monitor will execute the collection runner every given period of time. But, be careful — this service is charged by API calls! To avoid being surprised with the billing descriptor, take a look at the pricing page first.
Monitors works very well, but they do not have some features that collection runners has, such as importing or persisting global variables, file upload and direct access to your localhost.
8 — API Documentating
Like Swagger, Postman also generates documentations for your created collections, in real-time!
The generated documentations are browser-based, and you can choose between public and private access, customize pages with your team’s logo and name, use custom domains and even use markdown to create them. And everything in a few clicks!
And, like monitors, this service is charged. So, it’s very important to always take a look at documentations and pricing pages.
Postman’s app were created using Electron, so you can debug requests with the visual tools or simply open the console (DevTools) as if you were in the browser. Likewise, everything inside Postman can be imported and exported in JSON — collections, collection runners, environments…
At Postman’s docs you can find more information and clear examples of how to use all these features — from how to make simple API calls to using advanced monitoring services.
There are many other Saas which also do endpoint and API testing, like Insomnia, Swagger or SoapUI. But, IMHO, Postman has a lot of advantages because it’s really easy to use (pratically a plug and play), and it has a simple, concise and direct documentation.
Another plus for Postman — their YouTube channel is packed with tutorials with screencasts and a lot of tips of when and how to use each feature. Worth checking out and learning how to use!
Originally posted on Dev.to by Julio Lozovei.
In order to see how to make requests and integrate with CI runner like Jenkins, you can see my other post here.