Testing APIs on Postman: A quick look at some features offered by Postman
Testing APIs on Postman: A quick look at some features offered by Postman
Snowpal API: Do your development and/or testing teams have an interest in testing APIs on Postman? If so, how do they go about it?
The speaker discusses the increasing use of Postman over Insomnia for API Gateway work, citing uncertainty regarding loyalty shifts due to Postman's GraphQL support. They express interest in exploring Postman's features, including its workspace on postman.snowpal.com. While acknowledging Postman's strengths in testing endpoints and managing environment variables, they raise concerns about limitations such as the inability to tie responses between requests and the risk of vendor lock-in. Emphasizing the importance of considering team skill sets and needs, they advocate for managing dependencies in separate repositories. Finally, they highlight version control challenges and urge caution against using tools for short-term convenience that may lead to long-term issues, concluding with a call to explore Snowpal's products and subdomains.
Summary
Introduction to Postman and Insomnia:
Mention of increased usage of Postman in API Gateway work.
Uncertainty about shifting loyalties from Insomnia to Postman due to GraphQL support.
Exploring Postman Features:
Mention of Postman workspace on postman.snowpal.com.
Interest in exploring features previously not utilized.
Testing Endpoints with Postman:
Description of features for testing endpoints in Postman.
Mention of using JavaScript code for pre-requests and post-requests.
Environment Variables in Postman:
Discussion on managing environment variables in Postman.
Importance of having separate environments for different users and scenarios.
Challenges and Limitations of Postman:
Lack of support observed for tying responses of one request to another.
Concerns about vendor lock-in and inability to externalize code.
Decision Making and Best Practices:
Considerations for team skill sets and needs in choosing tools.
Preference for managing dependencies in separate repositories.
Conclusion:
Mention of version control challenges and doubts about Postman’s suitability for large-scale projects.
Caution against using tools for short-term convenience that may lead to long-term issues.
Podcast
Transcript
0:02
Hey there. As part of the current work that we’re doing, the API Gateway work, we’ve begun to use Postman a whole lot more than we have in the past. I’m not sure if we have shifted loyalties from Insomnia to Postman. I wouldn’t say that yet because I don’t know how well Postman supports GraphQL. We love Insomnia for a lot of other things, including its GraphQL support, but I’ve seen that they know, given that we published Postman, the Postman workspace on postman.snowpal.com for instance.
0:26
You can go check out our workspace there. We’ve begun to use that quite a bit, right? And we’ve tried to learn more of its features, features that we didn’t necessarily care for all along, which may or may not make a difference at this point. But there’s that. There’s one that caught my attention. I see other teams using it and I want to know, just want to share my thoughts on whether, in my opinion, whether it’s a good idea or not such a good idea doing it right.
0:48
I don’t know if I have a strong opinion. We’ll see as the video progresses. So let’s say we have, we have a number we all of our endpoints are broken down into different directories in the collection in our very first API, the one that we just went live with, and you can go to developers.snowpal.com to check that out.
1:06
Postman supports a number of these features to test your endpoints, right? So you can add some code like JavaScript code for instance. I don’t know if they support other languages too, but you can add JavaScript code that’s embedded like snippets into these endpoints and then they have pre-requests and post-requests.
1:21
What happens before you run a request? What happens after you run a request? And there are ways for you to create like test suite so you can run all the endpoints, all the test, all the endpoints in your collection, in your collection or in your directories, maybe under. I don’t know if they supported at the directory level, but I’m pretty sure they do and probably also at the collection level, right?
1:38
So those are convenient, but the thing here is right. I don’t I maybe they have support for it. I haven’t seen it carefully enough. But you have these values and your values come from these environment variables and you have multiple environments and you can have any number of them right? Not just by your but whether it’s by dev, test, aging abroad.
1:55
You can also have it by developer, you can have it by the user you’re going to be testing. You know, let’s say Chris is testing API user one against this and on this environment I can have an environment specifically for that. If somebody else is testing that same user on a different environment on the same one, they could have a different environment and have, you know, overwritten values for it, right?
2:18
So we do it all the time. That way you don’t run into each other, you know, interfering with other developers environments, and then you may have a global environment, but you’re not really touching anything else. You don’t want to be touching or impacting other people. That is fine, but those values are hard coded. I don’t know if Postman has any support.
2:34
I haven’t seen one where you can tie the response of one request to the other. Maybe they have a way to do that. If they do, let me know, right? And let’s see how. I mean, I would like to know how good it is and how graceful it is. If it is there, then it is going to be pretty powerful that that actually solves a part of the problem that was going to talk here right now that I think about it, but I don’t know if they do and if they do, to what extent, right?
2:59
But if whether they do or don’t, even if you made those decisions, you actually wrote the code, the snippets within Postman. The challenge there is you’re kind of married to the tool, right? Sort of to the vendor. And it’s not easy to externalize that and put it in a repo. Now if everybody’s just using Postman, your team and your testing team is exclusively using it and your developers are using it all the time.
3:19
That might not be a bad decision to make, but I still think of him. We don’t ask no problem. We don’t believe in vendor lock in. We use AWS, we use Google, Google Cloud, we use lots of languages, lots of stacks, we have polyglot. So we don’t like to be tied to or married to any one thing. Our interests abroad, the problems we solve are pretty broad as well.
3:38
So in that sense, if you want, if you wanted to at some point write it in different languages and externalize it outside postman, you wouldn’t be able to do that. That is a downside of using all the support a particular tool gives you. But on the flip side, you might argue that I don’t want to maintain another repo.
3:54
Maybe my team doesn’t write as much code at least this part of the team that’s doing all this testing so I’d rather do it on Postman. In that case I think you might still be you might be all right and and doing that kind of stuff so so make a decision based on what what your team skill sets are and what your what your needs essentially are.
4:14
We’ve sort of we lean on the side of creating our own repos to managing and maintaining our dependencies. So we do use Postman for some part of a testing, but something that’s quick and dirty, right? But some any part of our testing that needs that needs to be repetitive.
4:31
We most certainly do that in our own test repos and sort of manage and maintain it exclusively over there. And again, we the we use different languages for doing that as well. But you could just pick one, whatever it is, whether it’s Go or Ruby or Node or C# or Java, it doesn’t matter.
4:47
Whatever your team’s preferred languages, and you can build it on that. That way you’re not sort of. You don’t have these code snippets all over the place in Postman and and you’re going beyond that. There’s more issues that I can think of as I as I’m talking, right? How do you version control this?
5:04
I don’t know if Postman supports something like that, right? So maybe you have to create multiple collections, and if you did, maybe the code snippets you wrote on one one collection, maybe they don’t carry over to the other. So do you? Do you have a new collection, new version for every change that you make? What?
5:20
Let’s say we have 400 endpoints. How do we make changes to these endpoints? And if we’re not changing the definition of the endpoint, but just the code that runs around it, how do we version control that? So maybe now that I think about it, maybe this won’t even work on Postman. I mean, we didn’t even think it would, so we never bothered to spend even a day trying to figure that out.
5:39
It didn’t look like it would do it. And sometimes, a lot of times, you trust your hunch, having done this for a long time. But if all of this is possible, if all of this can gracefully actually be done on Postman, then it’s actually a much better tool than I think it is. I think it’s a good tool, but I don’t think…
5:55
I think sometimes I’ve seen people use it for things that are kind of convenient in the short term, but maybe you’re going to shoot yourself in the foot in the long term. So definitely be wary of that kind of stuff, right? That’s about it. Talk to you soon again. Go to developers.snowpal.com, learn.snowpal.com, snowpal.com.
6:12
There are plenty of our subdomains. Each of them is a different product, different client, mobile, web, API, and whatnot. But do check all of it out or some of it out. It’d be very much appreciated.
Thank you.
Snowpal Products
Backends as Services on AWS Marketplace
Mobile Apps on App Store and Play Store
Education Platform for Learners and Course Creators