One of the most common type of projects that we deal with in IT projects include calling a 3rd party API service and doing magic with the API. The most interesting projects are usually a mashups of different public APIs as well as internal APIs to yield interesting results. In data visualization & analytics, this can yield interesting insights on how your internal data stack up with public API results.
Any business analyst who have ever helmed such a project would face the challenge of managing multiple APIs and finding a common API test client to automate testing & verification of the APIs. I confess, I was one of those, who gave up finding an automated solution after trying out many different API test solutions. This changed when I met Postman.
Postman is available as a Mac app, but more importantly, it is available as a Chrome app — It’s almost a cross-platform app as long as your platform supports the ever-popular Chrome browser. Today, I’ll share how you can use Postman to automate your API testing on Postman’s awesome free use tier.
First, understand what makes up your API query
I won’t say that all APIs are same — in fact, having a common API design can sometimes be a compromise to your security. I recently encountered an API that was designed in very unconventional way:
- Instead of placing the query parameters in the standard URL query parameters, and separated by “&”, they used another symbol to represent “&”. Most API clients were immediately thrown off by this as they weren’t able to identify different query parameters.
- The parameters were not key-value pairs — they were data values and these values were pre-defined within the documentation. Most URL query parameters include key-value pairs and couldn’t recognize this unique way of constructing the URL query.
- As long as there was a response, the HTTP status was 200 OK. Many API clients rely on HTTP statuses to differentiate error & success messages. This API returned the call status in the response JSON.
- There was a use of SHA hashes throughout the query string — The API required pre-generated hashes to ensure that the URL query was not modified along the way from the client to the server.
Not all was a new design. There were some design that stuck to the conventional API design:
- Sending request data via the request body — For POST responses, the API continued to send data via the request body
- JSON request & response — All hail JSON! If you don’t already know what JSON is, you should do a quick catch up of what JSON is or check out W3school’s introduction to JSON.
To clarify, this is NOT a REST API. It might look like REST, but it wasn’t — It was still based upon the concept of procedures (i.e. Sign Up, Login etc) but was using somewhat of a REST invocation style. Many API designs that are making the transition to a RESTful architecture fall into this grey & challenging area.
Once you understand how your API changes, you know what you need in Postman. If not Postman, then any other API client — You would be able to quickly shortlist your API clients without going through the painful process of figuring out how to script test case, only to find out they can’t support the flexibility that you need.
In Postman, there are many variables that you can change — I chose to use environment variables and the request variables. Request variables in Postman allow you to add request parameters that turn up as key-value pairs in the “Params” section:
Environment variables was the key feature that secured my commitment to Postman — they allow you to change any part of your API and be inserted to almost anywhere in your API request. You begin by defining your environments:
Clicking on the selected environment, you would be able to see the whole list of environment variables and what are the “default” values assigned to your environment variables:
In this part, I have laid out some considerations when choosing your API client. Knowing your API well is the key to any API test project starting point, and knowing what clients are out there, and what cool features they have that differentiates them from the rest helps to shorten that search process. Next up, I would go in depth to doing up a pre-request script followed by doing up a few test cases & showing some cool in-built authorization features in Postman. Stay tuned!