Kevin Miller, DataMotion Security Specialist, recently celebrated his seventh anniversary here at the company. During this time, Kevin has worn many hats and brought a wealth of knowledge to the table, including his proficiency of the Postman API testing application, of which he can be considered a subject matter expert. He has helped many of his colleagues and customers understand Postman, and how to succeed with the tool. Kevin was kind enough to sit down with us to share his experience, as well as some tips on how to leverage Postman to its fullest capability.
Heather Post, DataMotion Developer Advocate: Kevin, thanks for your time. And congratulations on the work anniversary!
Kevin Miller: Heather, thanks—it’s a great achievement.
HP: Throughout your time at DataMotion, you have held a few different titles leading to your current position as the Security Specialist within our Engineering department. Can you tell us more about your role, and what that entails?
KM: Today, my duties include handling security documents and statements, ranging from our information security plans and operating procedures, to our business continuity and disaster recovery. Security assessments from third parties, especially the bigger assessments like EHNAC and now HITRUST, fall under this umbrella as well.
In the past, I worked closely with support and sales to assist with questions relating to API integrations or specific product integrations, such as those involving Salesforce and the DataMotion secure email content filter. I’m still happy to help both departments when needed.
HP: I understand that you have had the opportunity to use Postman extensively. Can you explain what Postman is?
KM: Sure! In a nutshell, Postman is a desktop application for performing web requests. As DataMotion provides an extensive number of APIs to go along with our system, Postman provides an easy way to quickly test those APIs or demonstrate their use if questions come up during conversations with customers.
HP: When did you first start using Postman?
KM: My first experience with Postman was back in late 2015 during the initial release phase for SecureMail 5.37 (now referred to as secure messaging center) when our REST APIs were first released.
It was easy to get the hang of Postman, and it helped us quickly test DataMotion’s REST APIs without the need to build an application to do so for each. The ease of use of Postman at the time lay in the fact that it was a GUI application that was able to perform API requests without requiring vast knowledge of programming techniques. All that was required was the appropriate URLs for the API requests and entering their expected request bodies. Then, all you had to do was click a button to send your request and receive an easy-to-read response. All of this is still true in regard to Postman today.
HP: Are there any specific projects where Postman plays a significant role?
KM: Most of DataMotion’s current projects involve API development, whether it be the original messaging products or the newer projects being integrated into the self-service portal for our customers to easily use. When creating a new API, we use Postman heavily to test functionality and to ensure the API will handle various parameters correctly. We also use Postman for internal and customer-facing demonstrations.
Therefore, I would say any time you are developing or adding functionality to an API, that is a great time to use Postman.
HP: What are some of your tips and tricks for using Postman successfully?
KM: I would advise several actions to make things easier when using Postman.
The first tip I would recommend is utilizing variables. If you have to utilize the same information in multiple API calls, you can replace this information with a variable and define the value of that variable for an entire collection of calls. Therefore, if you need a session key to run all of your calls but login, you can update this value in one spot rather than having to do so for each of the calls you will be testing.
My second tip is to create a set of environments that coincide with different sets of URLs. This is particularly helpful when working within our own systems, as many of the functions remain the same, but the base URLs change depending on the system. I simply create one of those useful variables for the base URL and update it based on which environment I will be using. This, again, saves time and the hassle of creating multiple collections of the same API calls.
The third action I’d recommend is very specific to our own messaging products, but is quite useful. This is to create a short console script in the ‘Tests’ category that carries the session key over to other requests in the collection. As an example of how this helps me, I have created a script that will update that session key variable that I mentioned earlier every time I call my Login API call. This streamlines the process of updating the variable and allows me to run any of my API calls directly after logging in.
HP: Can you explain what the DataMotion Postman collections are, and how they can be used?
KM: All of DataMotion’s Postman collections are geared towards its messaging products, and are best suited for development teams to test sending their expected payloads via API, or for those customers who have on-premise systems to test the APIs within their own environments.
HP: One last question. Do you have any advice for developers who are just getting started with Postman?
KM: For those that have never used Postman, it is a good idea to use a pre-built set of collections to get used to what a request in the application will look like, how to trigger the requests, and what to expect in the response. This will make you much more familiar with the product when it comes time to build and test your own API.
HP: Kevin, thank you for your time today, and for all of the great information!
KM: You’re very welcome!
For additional Postman tips and tricks, check out our blog posts “4 Tips for Becoming a Postman Guru” and “4 More Tips for Your Journey to Becoming a Postman API Testing Guru” which rounded up our Postman series on social media. Finally, be sure to follow us on Twitter, Facebook, and LinkedIn to catch our next tips and tricks series, which focuses on GitHub.
