Testing Secured APIs with Postman

Welcome to the PGA for our JavaScript meetup. I’m really grateful to my boss for opening up the space for us to host you here. Thanks for joining us. The talk today will be on APIs and Postman. Before I jump too far into it, I wanted to get an idea: is there anybody here not familiar with APIs at all? Do we have any complete API beginners? No one? Okay, so I’ll try not to go too deep too fast.

I do want to give a shout-out to Jason, who last month started what I hope is going to become a trend: learning to learn. I hope future presenters will take their cue from that and share where they like to learn from. I highly encourage everybody to keep learning. I don’t think you can be a good developer without learning something new probably every day, and it doesn’t have to be development-related. So commit to your ongoing learning.

Some of my favorite places are Stack Overflow. Basically, if you have a question and you search for it on Google, Stack Overflow will probably come up near the top anyway. If it doesn’t, you can go on there and find some very specific answers to some very specific questions. And if, by some chance, which is probably only about a 10% chance, they don’t already have an answer to your question, you can post a new one, and if other people have similar questions they can vote yours up. So it becomes a really useful tool. It’s also great if you have answers: you can learn by looking at what other people are asking and answering some of the questions, which can help you learn new things, or you might already know an answer and just help somebody out.

Pluralsight is a great website. Jason mentioned lynda.com before; there’s also egghead.io. There are several of these websites with video tutorials that are fairly in-depth, with a lot of information. All of them are great, including YouTube, which is free, but Pluralsight has a great collection of courses, and I wanted to mention it because it hadn’t been mentioned.

Podcasts are my personal favorite. Actually, audiobooks are my personal favorite, but there aren’t very many audiobooks on JavaScript, because you usually need some visuals: there are often code examples and graphics. But there are some great podcasts, and I made a list in my presenter notes. JavaScript Jabber is the one I’ve been listening to actively for a while now. They cover a whole lot on JavaScript, and they have some great guest speakers. NodeUp is a Node-specific podcast. 5JS is a really cool one: they just do five minutes of JavaScript, so you can learn very small things and stay up to date. ShopTalk, for CSS and some other stuff; they cover a lot. Developer Tea was one of the first development podcasts I jumped into. Development-related but not JavaScript-related: This Agile Life, Agile for Humans, Coder Radio, the Complete Developer Podcast, The Changelog, which does a lot of great stuff, and Software Engineering Radio. That’s just what’s on my list; there’s a lot more available if you search. So podcasts are definitely great tools.

GitHub may not be the most obvious learning tool, but it is a wonderful one. There are two kinds of learning I know you can do there. One is that there are entire textbooks published there that you can actually contribute to: not only can you read them, you can submit changes and examples. And there are some great tutorials you can follow step by step by going through the repo’s commit history. So instead of having to download a big zip file and go folder by folder, example one, example two, you go through one example and follow it from beginning to completion through the commit log. The second way is, of course, looking at some of the industry superstars and the kind of code commits they’ve made. Most of the best-known names probably have code posted in the open-source community, so you can just look through it. And if you’re brave enough, you can ask to contribute. Some of those communities will let pretty much anybody try, so if you’re good, you can end up with code in some major open-source platforms.

There are forums available for just about any technology and language. In the past I made use of the SQL Server forums a lot. There are some true experts who look at the questions and post some really great answers. So whatever language you’re using, JavaScript or any other, there are forums you should probably participate in.

And my most frequent note to everybody: give yourself the ability to fail. Success comes from the freedom to fail. I think Mark Zuckerberg has been quoted on that, along with many other tech leaders. But that doesn’t mean fail and stop. It means fail fast, fail often; some of the more modern versions are “fail forward” and “fail better.” I’m not going to explain the difference between each approach; you can definitely look them up. But at the bottom of it is the world-famous light bulb: a thousand tries, and then it finally worked. I tend to think of it as a failure every time I hit Ctrl+S and it doesn’t do what I want, which is pretty much almost every time I hit Ctrl+S, until it does. So don’t be afraid of failing, because the more often you save, and the more you commit your code and go through the versions, the sooner you’ll get to something great. Let yourself do that. Learn from every little failure, no matter how little it is. Always learn, always move forward.

So today we’re going to talk about APIs. API stands for application programming interface. My personal note is: they’re not scary. They might look scary, and there’s potentially a lot to learn about them, but in the grand scheme of web development they’re not the scariest thing out there. A good example I’ve seen for thinking about what an API is: consider an ATM. You walk up to an ATM and try to get some money out of it. Full story told, there are probably multiple APIs involved in that, everything from the hardware processors in that ATM on up. But if we simplify it, that ATM, one way or another, has to communicate with the bank it belongs to, or another bank, and find out: do you have enough funds to withdraw from which account? And then communicate back to you.

[Technical difficulty.] All right, we’re back.

So think of APIs as an ATM. Somebody comes to use it. They work with a user interface. There’s a program running in the background that allows the ATM to communicate with some sort of data server at the bank, and the bank returns the information it needs. There’s some sort of handshake that happens, and they agree on a data format in which they’re going to exchange the information, hopefully in a secure way.

So what types of APIs are there? There’s a variety, and I’m not even going to mention all of them. Some are hardware: every computer processor has an API, which is how the most basic programming languages work. Every operating system has an API, which is how higher-level programming languages work with the operating system. And the most friendly and relevant today are the web service APIs, used by pretty much every big brand name you’re familiar with, such as Twitter, Instagram, Google, and Facebook. I’ve used Flickr’s before to make some interesting tools. So if you’re looking to consume any kind of data, it’s probably available to you. You can write your own custom tools for Google’s products or Facebook’s products. You can make your own news feed if you want, or your own Twitter client, all that kind of stuff.

What do web APIs actually do? They allow applications or web services to communicate with one another: to connect to another server and its data, and to exchange data or get data from a server.

For web services, there are different API protocols. Some of the more common ones are REST and SOAP. GraphQL is probably the most recent one I’m aware of; it’s by Facebook. There are others, and there’s a link in here you’re welcome to read about. I don’t want to dive too deep into each protocol, but if you have questions I’ll do my best to answer them. Most of the work we’ve been doing lately uses REST, and there are some specifics to REST, but they all have something in common. You can definitely use Postman with REST and SOAP, and probably with GraphQL, although I haven’t tried Postman with GraphQL.

At the foundation of an API, you need a way to connect to what’s called an endpoint. Endpoints are usually identified by a uniform resource identifier, also known as a URI. You’re most familiar with URLs, the web addresses we go to every day. A URL is a subset of a URI; a URI is slightly higher level and isn’t protocol-specific. There are different ways to access APIs, called verbs. The most common one is a GET request, when you ask the server to give you something back. You can also POST to the server, which usually means submitting a form or something similar. A PUT usually updates existing data. And there are others I haven’t yet had a reason to use.

Audience: [A question about PATCH requests.]

It’s a good question, and I have a link for it. I’ve used PUT, I’ve used POST, I’ve used GET; I have not used PATCH, and there’s probably a reason for that. With Tim’s update on that, we’re going to go with the answer being: PUT is a multi-field update of a record, and PATCH is a single-field update.

You can exchange data in various formats. Two of the most common are XML, the Extensible Markup Language, and JSON, JavaScript Object Notation. XML is only a couple of years older than JSON. It just so happens it was the first data language I learned, and I really liked it. JSON seems to have quickly surpassed what XML is capable of. There are arguments about which is more readable. Because I learned it first, I think XML is actually more readable than JSON, but anybody who loves JSON will probably tell you otherwise. I had some more dictionary-style definitions of each, and the JSON website calls it “a fat-free alternative to XML.” So those of you who are health-conscious probably want to use JSON.

The next thing I want to show you is a very basic example of what an API call looks like, not in Postman. I spent several years working with APIs and didn’t need Postman, because those APIs were publicly available. I’m sure several of you are familiar with clicking a link, going to a browser, and seeing a data response from a server. This one happens to be in JSON format. This particular data set comes from a wonderful website that gives you information on countries, and it’s publicly available.

Now, what is the biggest problem with making this available to us? Anybody? It’s not secured. If we were malicious and decided to tank their server, we could. Or say the Olympics were happening, and we built an app that relied on their API for working with countries, and it became really popular. Not maliciously, just by being a good citizen, you could still potentially tank their servers, because they’re completely wide open.

Here at the PGA, we ran into a similar issue with our scoring system. Our first generation of data feeds was publicly available: we shared it with our partners, and we relied on the fact that most people didn’t know those URLs, those endpoints, so we weren’t too concerned. Until it just so happened that, in good conscience, some of our partners forgot to turn off some of their old apps, and they just continued to consume our old API, adding more and more load to our servers. So this year we’re transitioning to a secured approach.

There are several ways of securing your APIs. Some of the more popular ones are API gateways. Amazon provides a wonderful tool; well, maybe “wonderful” is an overstatement, but a useful tool. It’s very cheap, something like a couple of dollars per million transactions. It’s almost free, not quite free: if you have a popular app, you’ll actually pay them something. It’s simple but not easy: it does have a learning curve, but with enough tinkering you should be able to figure it out within a couple of hours. Apigee is a great company that also does API gateways; they’ve been acquired by Google, so that should mean something. I’ve been to some of their presentations, and they were very informative. OAuth is another way to secure them. And there’s the custom way.

In our case we went custom, because we had a very finite number of partners who had already implemented our data feeds, and we wanted to give them the minimal amount of change, which we could hold their hands through. So it was a very specific use case. If I were giving somebody advice, I’d say go with an API gateway if you’re getting started, and it’s probably where we’ll end up in the near future as well.

But what would you need for custom security on your API? At the very minimum, you should issue your clients or partners a public key. And you should hand-deliver them, on a napkin, a private key. Well, that’s what the federal government says. There’s actually a website I found called onetimesecret.com, which works wonderfully. You can set how long a piece of text will exist, protect it with an extra password, and send it to the partner, and once it’s been opened it’s no longer available to anybody. So if somebody opens it before they get it, you know there’s been a breach, and you can reset that key. So there are digital ways of doing it, but according to our federal government, private keys should be delivered in person.

The third piece you need is a timestamp. It isn’t essential, but it’s highly recommended, and it’s used to establish the timeliness of the request: once the key is created, it’s only valid for a certain period of time. We chose 60 seconds before or after atomic time. Because not every server is in sync, it might be better to make it maybe two minutes before and after, just to make sure nobody’s clock is that far off. For non-essential data, some people make it hours or days before access is revoked for a token.

And then you calculate the hash. In the not-so-distant past, people used the SHA-1 algorithm. It’s since been, well, “hacked” is probably not the right word, but people have found a way to create a duplicate hash from a different source. So we’ve used the SHA-256 algorithm for the hash; that’s the standard right now. Give it a few more years and it will probably change again.

Once we implemented custom security for our APIs, I quickly realized that to test in the browser, I had to go into SQL Server, run a query, grab the key, append it to my URL string, try to test it, and then within 60 seconds it had expired and I had to do it all over again. So it became a very difficult task, and I quickly realized this was not the right tool for testing. Very quickly, within a few minutes, some of my friends and co-workers were raving about Postman. So lo and behold, I had to learn it, and I was really excited. We did a short show-and-tell at a JavaScript meetup once, where people told me I should really make a presentation about it, and here I am. So let’s learn a little bit about Postman.

Audience: [Which browser plug-in formats the JSON on screen?]

Oh, that’s not the one… I do believe I’m using a syntax-highlighting plug-in; I think it’s called JSON Beautifier or something along those lines. If you look in the Chrome extension store, there’s a bunch, and they all make it look slightly different: different colors and whatnot. Good point, thank you for that. There are a ton of tools available.

Postman started out as a Chrome extension, and it still exists as a Chrome extension. I love that they made a desktop version, because I can run it separately from my browser. They’ve since added functionality so you can use it from a command line, you can schedule tasks with it, and you can use it as a server to test against, to provide mock data for your applications. But it started in the browser, as a Chrome plug-in, and there’s a whole lot of cool stuff you can do with plug-ins if you’re not using them.

The main difficulty, which was solved by my favorite Postman feature, the pre-request script, was that the API required a timely signature. My first instinct was maybe to make that time frame longer in development: instead of 60 seconds, make it 60 minutes. But even that would be annoying, because every 60 minutes you’d still have to mess with your hashes, figure them out, and put them in the browser, and it’s just a mess. The browser also doesn’t give you an easy way to work with a lot of different endpoints, and definitely no scheduled tests or anything like that. So my first hurdle was: oh my god, I need to change this hash token frequently, and I don’t have a quick, easy way of generating it and putting it in the browser for every request, because in addition to the hash token you also need to provide the time string. That’s a lot of copying and pasting, which Postman quickly and easily solved for me.

A Postman overview. It handles a lot of different things for you. As I already mentioned, you can do regular GET requests, POST requests, and any other verb. It handles responses in just about any format. It handles collections of endpoints, so you can create endpoints per project, per topic, per client; it gives you a great way of managing collections of endpoint URIs, and folders within those. It gives you a way to create test suites, where you test what comes back from every endpoint to make sure it’s working correctly. You can string requests together, passing data from one request to another, in what they call collection runs. And you can run it as a local server that takes snapshots of your data and feeds them back to your apps for testing. I haven’t quite explored everything it does; some of it I’ve only read about, and I can share the details with you. Their documentation is wonderful.

They have environments, so with one click you can switch between your development environment, staging, and potentially production. And fortunately for this group, it works with JavaScript. If you’re going to write your tests or your pre-request scripts, which is my favorite feature and which I’ll go over shortly, they’re in JavaScript, which should mean it’s easy for you. That might not actually mean it’s easy, but for JavaScript developers it should be a pretty small learning curve. And they have some of the most popular libraries baked right in: CryptoJS is part of Postman, so you can use it right in there; Lodash is right in there; and there are several others.

They also have developer tools baked in, very similar to, but not identical to, the Chrome developer tools, so you can do your console.log and similar things to see what’s actually happening. When I first started, I didn’t think that was in there, so I had to find a workaround. So I’m going to show you one more great way to learn and share code for small examples: it’s called JSFiddle. There are several others, clones I’d call them, which basically do the same thing. CodePen is a wonderful tool with great CSS examples. They all basically do the same thing.

Before I wrote this little piece of code, which is literally about seven lines of JavaScript, I needed a way to test that my logic produced the correct output that my back end wanted. Fortunately, the private key here is a test key, literally a string, so no real keys are being exposed. I used JSFiddle. The hardest part of the whole thing, going back to Stack Overflow, was finding a host that had the correct version of the CryptoJS library available. I probably spent more time than I should have looking for a CDN with the correct version. Most examples on Stack Overflow pointed to Google, and Google had moved it, so literally everything about CryptoJS on Stack Overflow as of eight or ten months ago was outdated. I probably should have posted the new link on there. In any case, I wrote a very short script, and this is probably not even the best way to write it, but all I wanted was the correct steps in sequence to give me the result I wanted. Then I was able to take this code and literally copy and paste it into my new best friend.

Before I show you how that piece of code works, I’m going to go back to my very first example, just to demonstrate the most basic use case for Postman: take a URL that points to an API, put it in the field, hit the Send button, and down here comes your response. At this point you’ve gained nothing over doing it in a browser, but it is formatted prettily, and it gives you a couple of different ways of viewing it: raw data, text. It’s helpful in some ways: you can see how big the data is and how long it took. But it doesn’t give you all that much at this point.

The very next thing I was asked to do was create a prototype for consuming an API through the Amazon API Gateway. It did not take very long, but the biggest hurdle was finding one piece of documentation that was very hard to find, and I’m going to share it with you first. If you’re going to use an AWS Signature for requests that come through the Amazon API Gateway, there’s one thing that’s mentioned in only about one place on the internet, and even there it has the capitalization wrong. What you need is this extra header called x-api-key.

This is only required if your API requires it, so maybe I should show a small glimpse of this. This is roughly what the Amazon API Gateway tool looks like; this isn’t all of it. Within it there’s a way to test, and within the method request there’s this little setting called “API Key Required.” We had it on. I didn’t even know whether it should be on or off; it sounded like a good security measure, so I had it on, and nothing would work. Everything else seemed to work except that part. I’ll show you what happens if you don’t have that key: in Postman you can turn any header off and see what the result would be. It kept telling me I was forbidden. I’m like, no, I’m not; I know my keys are correct. I pasted them again, I generated new keys, I followed every step in every guide, and it just would not work, until I finally found that the fix was adding this extra header. And lo and behold, poof, it works.

There’s one more thing I wanted to mention on the Amazon side. They have this thing called stages, where there’s a URL you can click, supposedly to test your endpoint. Oddly enough, when I click it, I get a similar message saying it’s missing an authentication token. And I was like, well, that’s kind of the whole point: shouldn’t I be able to click this to test that it’s working? And now it wants me to authenticate. So what do I do? Inside their Resources tab, they have this Test lightning-bolt button. If you’re in there looking for it, hit Test, and it will actually work. So they do have a way to test a secured API through their gateway. For whatever reason, the most obvious place, the Invoke URL, doesn’t work when you click it. There should be a button that says “make this work,” or a link to the test.

Back to Postman. This is the same URL I got from the API Gateway, copied and pasted in here. Under Authorization it defaults to No Auth. If I try it that way, at this point it will actually still work. Want to know why it still works, even with No Auth? You’re not allowed to answer; you already know the right answer.

It’s partially because all the other headers are already present: once you make the request, the tool is basically caching your headers for you. The first time you make the request without authentication, you’ll get “missing authentication token.” Once you add authentication, which I can demonstrate, and delete these keys but leave the x-api-key one, there’s no missing authentication token. Switch the authorization to AWS Signature.

This brings me to another of my favorite features: a way to use your keys without having to expose them, in a demo at least, or in your collection. Some of the power of Postman is that it lets you share collections and environments with your co-workers, partners, and so on. But say you want to share all your code but not your personal keys, or your company’s keys. You can share the collection with the variable names assigned, and the actual keys are something the other person plugs in on their own, in their environment. So they can take your code, plug in their keys, and it will work, as long as they have access.

The keys exist in a couple of different places. Up here in the upper right corner, hopefully you can see, is where you define the environment you’re working with. In this case I’m working with PGA Production, but if I hit that drop-down I have PGA Dev, and you can set up as many environments as you want. If you click this little gear icon and go into Manage Environments, those are the two I’ve been working with. Under Globals are the global variables you want available to all your environments. In my case, the key for the scoring system test is universal across environments, so it’s in the globals. It doesn’t have to be, but anything that needs to be shared across environments can be global, and it works exactly the same way. To define them, you click in there, give it a name, and type whatever you want. You can also set them programmatically, which I’ll show you shortly.

Any questions on the Amazon example before I move away from it? No? Okay. The next example is some of the custom work we’ve built. A simple example would be “get event details.” In our environments, I was able to put a different URL prefix for development versus staging, so to hit the two different environments, the only thing I have to change is the environment, and it changes this URL.

The second thing you’ll notice is that I use variables that are pre-calculated. This is my favorite feature: this pre-request script, which is straight-up JavaScript, and as I mentioned, it’s a copy-paste of what I had in JSFiddle. In here I’m able to access my global variable. It’s too small? That’s as big as it gets, I think. Anyway, you say postman.getGlobalVariable, give it the variable name, and it gives you back what you stored in your globals. You can set and get your environment variables in a very similar way. Whatever your logic does, you can get values out of variables, or set them into variables with a particular name. So the variables you saw in my environment, K, DT, and H (probably not the best variable names), came from here. I didn’t have to type them in. Not only do I not type them in, they also change every time I run the request. Whenever I submit the request, it goes through and says: what time is it now, what should my hash be for that time frame? Then it takes the results and plugs them into my GET request, appended to my URL.

Using a variable is very simple: you put double curly braces around it. People familiar with Angular or similar will recognize it. The base of the URL comes from the environment variable I set, so if I switch to production, it gives me the production URL. The part in between is the actual endpoint, which changes per endpoint. If I hit Send, hopefully everything will work. Oh, thanks. Live coding, love it.

Good catch. In this case, it’s a very simple endpoint that gives me the event name and a couple of pieces of information about an event, like its ID and how many leaders we want to display. To go back to my argument that XML is prettier, here’s an example of a very similar XML data endpoint. I think it’s very easy to read: each element has a node within it; it’s so easy to follow. Pick your poison. This is not fat-free, supposedly.

On the API side, I have a very similar implementation that calculates the hash. In our case it actually happens inside SQL Server, and it’s insanely fast. What you need to provide, as I mentioned, is the public key, this K variable, which is known to both parties. It has a date for when the request was executed; mind you, I did have to add URL encoding around the date, but that’s done after the date is used to calculate the hash, which could be a potential problem for some people. And then there’s the actual hash, calculated by my pre-request script. It’s really as simple as taking those things and putting them through the CryptoJS SHA-256 function. It’s too small, but right here, it requires that empty string at the end. I don’t know why, but if you don’t put it in there, it won’t work. So just follow the examples on Stack Overflow or any other resource.

The server takes the public key, and it takes the date and converts it back into the date format it needs. It knows the private key for the person making the request, based on their public key, so the private key is never exposed, even outside the database. Then it uses the same SHA-256 algorithm on those three elements together, and only if the hash signature sent with the request matches exactly the hash signature the server calculated does it let the request through. When I was playing around with it, I was doing it with some test values, shown here. This is what the signature looks like: kind of gibberish. There are several requirements, again: the encodeURIComponent is important, which means you have to decode it on the other end, and the same goes for the date. So there are a few little hurdles to overcome if you’re doing your own custom security. But if you can avoid doing your own, I still recommend it: pick your poison, go with Apigee or the Amazon API Gateway, pay them a few cents, be done with it, and let them handle most of the hurdles for you. There are libraries out there that can help people authenticate, but the downside is that you’re basically forcing your users to use whichever gateway you’re using for authentication. If it’s Amazon, they’ll have to have IAM credentials available, so if somebody isn’t familiar with that, there’s an extra learning curve for them. But there are so many guides available now that I don’t think it’s an issue anymore.

Audience: [Can the pre-request script do more than calculate a signature?]

Absolutely. Not only that: it’s JavaScript, so pretty much anything you’d do in JavaScript you can do in a pre-request script, including all the libraries that come packaged with Postman. Further, you can use the results in the tests that run right after. You can take the results of that script, change your environment variables or create new ones, and then pass them into another request in your collection. So you can string them together. Let’s say: give me the current event ID. Okay, here’s my current event; now give me that event’s details. Okay, what round is that event in? Third. Now give me the scores for the third round. Now give me the players for the third round. Now give me the leader for the third round. You can string them all together into one test suite collection. I haven’t actually done it, but I do know where to go to do it. I think it’s the three dots… there’s a Collection Runner.

Speaking of user experience, overall I love their UI, but there are a few things that drive me nuts. Like this circle: I have no idea what it means. Up here it means it’s not saved, but down here I don’t think it means it’s not saved. They also have two buttons that do almost the same thing: the three dots, which we’re all familiar with in user experience as a menu, and this other thing that also gives you a menu. They’re still improving it; it’s wonderful. They have a great support forum, you’re most welcome to comment on there, and they take a lot of things to heart.

The Collection Runner is also where you can share with your teammates. They have different pricing structures: I think if you want to share within your organization you pay them a little, and if you want to share outside your organization you pay a little more, something along those lines. I’m no expert on their pricing; they have a Pro model and an Enterprise model.

Audience: [Is the version you’re showing the paid one?]

I don’t think I have Pro on my laptop, so this is all free. It does let you sync three computers at the same time, as long as you’re the same user. So I could be working on here, save something, and it’s already available on my desktop downstairs. That’s free: you get three concurrent connections.

If you want to run a collection, you hit this Run button. It opens the Collection Runner and gives you a whole bunch of settings: iterations, delay between requests. And this is about as far as my expertise goes. They now have Newman, which I guess is a joke on “Postman,” that lets you run things from the command line. They have amazing documentation for all of this, so you can walk through it step by step, and they have some videos that explain things, plus countless people on YouTube and other channels who’ve made excellent demos.

But for almost any developer who likes their development environment dark, the first thing you’ll want to change is under File, Settings on a PC, or Preferences on a Mac: go into Theme and change it to Dark. If it weren’t dark, it would be blinding, in my opinion. This is a must-have. Any other questions?

Audience: [How do you keep the API keys you use in Postman secure?]

That is a very good question, and I don’t think I’m qualified to answer it fully at this moment. But I would say you want to issue API keys with care, where you actually know where they’re being used. Your Postman instance should probably have a dedicated API key, and if you start seeing requests come in that you can tell aren’t yours, you can reset that key and know right away that something fraudulent is going on. The best advice is to use them with care and change them with some frequency. Personally, I’m not too concerned in this case, because our data used to be public, so this is a great way of limiting some of the risk, but we weren’t that exposed even when it was public. If you have sensitive data, I would take a lot more time and care with your keys, and with the best way to protect them, update them, and share them.

Secret keys are challenging, and that’s part of what an API gateway can help you with, because Amazon keeps track of the stats, so you can see who’s calling and how often. If you’re in Postman, you’re probably not hitting an endpoint several times a second, so if you see requests coming in very quickly, it’s probably not a human developer doing it, and you can put some safeguards around that. There are definitely best practices for managing and storing keys in general; security by itself could be a university course over several semesters, so I’m not going to try to cover it all. Tim has actually had a bit more experience than me recently with how to properly secure keys.

I will say that I’ve seen way too many times that people’s passwords are stored as plain text in databases. Please don’t do that. At the very least, store a hash of the password, not the password itself. That’s not perfect, but it’s better than plain text. Take Equifax, with 143 million records out in the world: if they had at least been hashed, they would have been almost useless to the people who got them. Hashing gives you a pretty serious level of protection. So with any sensitive data, at least do that, and research how best to protect it beyond that, because there are definitely best practices around it. Anything else?

That was pretty much all I put together.

Audience: [How would you write automated tests in Postman, and could they move to Node?]

I know half the answer to that question. As far as writing tests, it has this great Tests tab, and they give you some examples. I haven’t messed with it too much, but here’s a very basic example: you can send the request, run a function afterwards, check how long the response time was, and get to the actual data, like checking that the body matches a particular string. It can get much more complex than that, so you’d have to read the documentation for all the tests available. Visually, it looks similar to what I’ve seen and done in Node, but it’s not a one-to-one syntax. There’s probably a library they’re using behind the scenes, and if we figure out which one, you could probably migrate it over to Node. At the same time, if you’re doing it in Node, you probably don’t need to do exactly the same thing in Postman. The automated part can be done in either; this is more of a front-end helper.

And if you don’t have Node, it can help some people set up mock data. One thing I didn’t show: up here there’s this thing called Examples. This is another user-experience note: these are not examples for you as a user; they’re examples for your users. You can save the results that come back from a particular endpoint, along with the response codes and all the header information. Not only can you save them, you can modify them, so you can mock an error, and what the data would be. Then your front end can hit Postman as a web server and get all those mock responses. But it’s not the only way; you can absolutely do the same thing with Node, and there are some great npm packages for that.

Audience: [What is Newman?]

Newman is the command-line interface for Postman, built by the same people. I haven’t actually tried it yet, but I’ve read quite a bit about it, and it seems useful. Anybody else?

Audience: [How do you version your tests?]

That’s another really good question. As far as I know, versioning is definitely easier in the Node world. In Postman, the only way I can think of is that you can clone collections: go to the collection, clone it, and give it a version number. You can also export collections, so you can export with a version number and put those in Git, but it’s not nearly the same, and it’s kind of a hacky way of doing it. There might be a better answer to that question that I’m not aware of yet. Anybody else?