Programming Throwdown - Building and Testing Web Services with Postman

Episode Date: May 31, 2018

Web services are for much more than building websites: they are one of the most common techniques for passing information among programs. Creating a web API for your program is a great way to access it from a browser, another program, or a mobile app. Today we chat with Abhinav Asthana, CEO of Postman, about building, scaling, and testing web services! Show Notes: https://www.programmingthrowdown.com/2018/05/episode-78-building-and-testing-web.html ★ Support this podcast on Patreon ★

programming throwdown episode 78 building and testing web services with postman take it away jason hey everyone so i'm here here with Abhinav Astana, and we're going to be talking all about web services. And before we jump into web services and REST and API and all these things, Abhinav, why don't you kind of introduce yourself? Tell us sort of your background and tell us a bit about Postman. Sure, yeah. Thank you, Patrick and Jason, for having me on the podcast. Really great to be here. So let me start with a little bit about myself. I have been a programmer most of my life until recently,

kind of moved into something more on the management side, I'd say. So I started programming kind of in sixth grade have uh been a self-taught programmer uh uh got an engineering degree but that was kind of in electronics so so what what did you make in sixth grade like a video game or something uh so i started with uh you know first i started with, you know, first I started with basic, you know, like the stuff that was taught in school. And then I kind of went to C++. And my dad was like, you know, very interested in programming. So he used to learn stuff like Visual Basic and Visual Fox Pro. So I'm going to pick that really up. And from there, I kind of went to Flash and ActionScript. Okay.

And then ended up making a web app through some sequence of things on PHP and MySQL. That's what I remember. Cool, cool. Cool, yeah. So, yeah, you know, I've been working on code for a while and through, you know, this kind of experience of like writing code ended up doing a bunch of friends in school and in college. We used to kind of, you know, design and develop apps and websites for other people. You know, we take up consulting projects, kind of get paid for it, which was pretty cool. Well, that's pretty like entrepreneurial, right?

Like you're in college and you're doing these projects on the side and kind of already sort of starting a business and getting a brand and all of that? Yeah, you know, it was, I like coding a lot and, you know, it's doubly awesome if you get paid for it. Working with clients at that time was tricky because, you know, you have school to kind of go to, but I liked it a lot and it taught me a lot in the process. And I kind of, you know, knew that whatever I'm going to do after college is going to be related to programming or, you know, designing something.

I didn't know about products very well at that time. You know, we just used to work on websites or web applications then. But yeah, after college, I found my first company with a bunch of folks that was called Teleport Me. And there I was basically building what you might call a social street view sort of a thing. This is in 2010. We were kind of building an app that would help you kind of capture panoramas and share it with the rest of the world. And we built that on Android. So it kind of got featured on the Android app platform. So it was pretty interesting.

We raised a bunch of money and had a lot of fun, you know, while working on it. But, you know, kind of after that, I started Postman as a company. So Postman as a project had kind of existed for a while, like, you know, as I was coding and working on stuff, you know, I used to work with APIs a lot. And Postman kind of came off as a side project of mine. And now, you know, of course, you know, it's like a company, you know, people and, you know, we have products and things like that. But yeah. Cool. So we'll talk like more in detail about Postman, but just like, can you give us kind of a one liner of, you know know what is the sort of core product yeah so postman is an api dev environment which helps you uh you know design test debug uh document and monitor apis

cool that makes sense so uh so is it specific to like web or is it, I mean, does it work with like shared libraries or it's probably mostly web, right? Yeah. So the APIs in this context that we help developers work with are HTTP APIs. Okay. Yeah. So if you have stuff kind of going over the network and it's on HTTP, that's the stuff that we help you, you know, build and test. Got it. That makes sense. Yeah. So if you have stuff kind of going over the network and it's on HTTP, that's the stuff that we help you, you know, build and test. Got it. That makes sense. Yeah. So, you know, a lot of people, I mean, you know, even my grandmother, when she hears HTTP, she kind of knows, oh, it's the Internet and Web pages. And so most people have like a basic concept of, you know, I go to HTTP, you know, Google.com, and I get the search box, right? So, you know, what is sort of the difference between, you know, I type in google.com and, you know, the kind of web services that you're talking about, right? I mean, they have HTTP in common, but, you know,

they're kind of very different user experiences, right? Yeah, I'd say from a user experience standpoint, they are different. You browse websites using your browser, whether it be Chrome or Safari or Internet Explorer. For APIs, what we are seeing is essentially what used to be done kind of in a very complicated way a few years back can also now be done on top of HTTP. So like the underlying technology is the same. In one case, it helps you produce websites. And in other cases, it helps you connect applications together, which is what kind of we call, you know, APIs. So yeah, the underlying stuff, like the building blocks are the same, but the way you use it

is pretty different. And I guess, you know, we can dig into that in more detail as we go through the talk. But one of the most interesting things that we have seen is that because of these two, you know, things being built on the same technology stack, you know, it has kind of led to the adoption of APIs. You know, it has made the adoption kind of much faster over the years. Yeah, that makes sense. Yeah, and you can even, there's a lot of different websites will actually give you, you give anyone access to sort of the more programmatic

or I guess the API of their site. So for example, you can go to duckduckgo.com, which is a search engine and you'll get the box and you can type in the box, you know, whatever you want to search for, dog, and you'll get a bunch of links to dogs. And it'll look, you know, they'll render that web page in a way

where it kind of makes sense and it's pretty easy to navigate, right? But you can actually do, and I think it's as simple as just api.duckduckgo.com. And then, I think it's too technical, but then you put a little question mark, q equals dog. So if you type that URL, you're going to get something very different. You're going to get what's called JSON, which is, what is it, JavaScript object notation, I think. But JSON is its own language. And you're going to get just, it looks like just a bunch of source code. What that is, is that's data that's been structured in a certain way.

It's not going to look pretty. It's not going to look anything like the DuckDuckGo landing page you're used to. And that's because it's ultimately not really meant for humans to read. It's a way for computers to, you know, or let's say computer clients to go and, you know, make calls to DuckDuckGo, and then for programmers to get data in a way that they can easily interpret. And then they can choose to do whatever they want with that. Yeah, absolutely. And that's, I think, one of the most interesting things about, you know, things like APIs. You know, once you kind of get that data in that format, you can kind of do lots of cool things with it. Like, I remember kind of going back, you know, when you had to kind of get data out of a website,

you would probably write like a scraper or you'd write a script to kind of take data from whatever was written into that document, in that HTML document. And you try to kind of build something to get that. Now it's much easier. You just kind of get the right API URL. And once you have that data in that structured format, you can build applications or just use it in very interesting ways. Yeah, and a lot have that data in that structured format, you can build applications

or just use it in very interesting ways. Yeah, and a lot of public data, like for example, if you want to see all of the penalties from a hockey team, well, the NHL has their database and they have a website. So you can go to,

I don't know what the URL is offhand, but you could go to the NHL's website So you can go to, I don't know what the URL is offhand, but you could go to the NHL's, you know, website and you can put in, you can actually, you know, in your browser, type in, you know, a certain query and you will get back a bunch of data. And so, you know, if you look at all of these apps, they give you up-to-date scores on sports events and things like that. Most of them are using this api and you know the census has an api and so there's just a treasure trove of information that you can get um so why how did

this end up sort of getting tied together with with http as a protocol in other words like why did this evolve and not something completely different that would return the same data, right? Yeah, no, that's a really good question. And I kind of found the answer a bit later, or at least I thought about the answer a bit later after Postman took off. Earlier, I think a couple of decades back, there was this whole notion of web services, right? So you had things like SOAP protocols, and the whole idea was that, okay, when we want to transfer data from one point to another, we would build this protocol, and this is the way things need to talk to each other. It was pretty verbose and pretty complex.

And it took off, I guess, within the enterprise, but didn't really take off so much in within the wider kind of developer community. What I saw and what I myself used were was like things like frameworks for PHP or Python, you know, so whenever you'd be building an application, and you had to kind of get some data from the user, you would have a web form, you know, show up on your web page, and then the data would be transferred to your server using a post HTTP call. So I guess the APIs were there, but they were mostly in the background. Now, I think a few key things happened that helped APIs kind of grow on top of HTTP. So the first one I feel that was pretty significant was the introduction of, you know, kind of the iPhone and the rise of smartphones in general. So what developers kind of started thinking was that I have to build an application first for the browser and now for a device. And I want to make sure that I do kind of less work and let me standardize on whatever framework

I'm using, but I'm going to make sure that this data gets sent off in a way that my smartphone can consume. So I think that was one bit. And then along with that, I felt what really helped solidify this was Ajax, where you would as people thought about the name, the name was kind of all wrong. The whole technology was built on top of HTTP, right? So what I think slowly started happening was people really wanted to build like interactive applications for the web and kind of more feature-rich applications for the smartphone. And, you know, kind of developers typically take the most pragmatic approach, if taken together, as a whole, as a community. And they were like, yeah, you know,

we have these building blocks available. We have these frameworks available. JSON as a data format is pretty easy to use. That kind of became the dominant format. And I guess it took off from that. Yeah, that totally makes sense. I remember, and I don't know exactly what year this is. I guess it took off from that. Yeah, that totally makes sense. I remember, and I don't know exactly what year this is, I think it was around 2002. But I was one of the first people on Gmail. And I remember just being on Gmail, and then all of a sudden, a new email

arrived, just while I was on the page on the web page. And that just blew my mind, right. And, and I think similar people had that experience again when when they saw google maps you know a year or two later and it's just you could just scroll forever and it would just show you the next city you know the next city and it just uh it just it felt like uh everything was on your machine even though it was it was being fetched in real time, right? It gave you this illusion like you really had the whole earth on your laptop, right? Right.

And so, yeah, I think those are some incredibly powerful user experiences, and they only worked with web services because that's the only thing the browser really understood. Yeah, absolutely. I mean, I remember using Gmail back then. I think I waited for a while to kind of get the invite. But once I got it, I was like, wow, this is one of the coolest things. Because, you know, you used to kind of refresh the web page and it would be like, you know, why doesn't this thing do it itself? i think yeah i think everybody saw that experience and then you know we're like yeah we need to have that too yeah totally hey patrick did you did you get a gmail invite from me or no it probably did come from you now that i think about that

so so uh um yeah so that uh i remember giving invites to people and there's times where they actually had a website where people were offering things for Gmail invites. And the one, I don't remember all of them, but one of them was they would give you, they're a tour guide in New York city and they would give you a tour of New York for free. If you give them a Gmail invite.

Yeah. It was, it was that trans transformative, a technology that people were just like, isn't that crazy? Yeah. You had to wait so long. Like so many people were just lining up. Isn't that crazy? Yeah. You had to wait so long. Like so many people were waiting, trying to get invites.

Yep. Yeah, I got by through Topcoder. And then, yeah, I gave everyone I knew, I gave as many invites as I could. I think I had 75 invites to give out. Or no, I think it was 20. And then later on, they gave me 75. And I never used the extra 75 wow yeah i remember when you know whoever would get the gmail invite like

that person would be you know like they they get like this cred in the local community that this is the person who has gmail invites and they'll kind of i mean i guess that helped gmail spread uh like crazy uh i guess the storage space and uh the experience like all of it kind of came together i mean i still use gmail so they're right like yeah i mean it was a great product i'm sure there's some really fascinating marketing books written on on you know how they really made the exclusivity just really drive up the value and make everyone just talk about Gmail. I'm sure. Yeah, absolutely. So getting more into, you know, testing and reliability and all of that.

So, you know, let's say I build some web service. I spin up AWS Node and, you know, I have some web service, I spin up AWS node, and I have some web service. I build an Express or one of these frameworks, right? How can I make sure that's reliable, right? I mean, the machine could die. People could pass crazy things to my web service. It's totally exposed on the internet. So I have to accept all sorts of, you know, requests that might be crazy. Like, how do you build a reliable

web service with all that uncertainty? So, yeah, I guess that's a broad question. It kind of depends on the extent of, you know, how big the service is. I've seen kind of our own set of services go from, like, you know, very simple things to really large things. But I guess let me start with the typical developer workflow, right? So one of the first things that I kind of observed was the ability to kind of query the service and know its behavior as a developer. So, you know, you're writing code and you're deploying code onto AWS and you kind of want to check whether the API works as expected. So, you know, you can query it with tools like Postman.

As your, you know, service becomes more mature, you would probably want to write more automated kind of tests for it. You know, you can check it, of course, you know, every now and then, but you can't be sure that when you're not checking, you know, it is working as expected. So you could, you know, build some automation around it. And there are, you know, a whole lot of ways in which you can kind of do that.

Folks can write unit tests. There are integration tests, lots of different options available here. And, you know, once you have, once you know that, okay, most of this stuff is working, I've checked it manually and I've checked it in an automated way

and I've deployed to production and my service is working out there, you can monitor that service for correctness and whether it's performing up to expectations. So you can have an external kind of monitor set up to ping your service and let you know whether things are working as expected. And I guess on the notion of reliability,

there are lots of internal instrumentation that you could do within the service to, you know, if you're emitting logs from the service and that is something that you can process and check for on the server side and make sure that everything's working as expected. The way I kind of see it is that it kind of goes through different stages

and those stages kind of depend on where you are in the development lifecycle. In the earlier stages, you'd probably be more ad hoc kind of playing with the service yourself. And as you go probably be more ad hoc, kind of playing with the service yourself. And as you go more and more towards putting that service out in front of users and it starts getting used, you would tend to use more automated tools for that. Got it. That makes sense. So it's kind of like the service kind of works like it it makes this request so for example going back

to the duck.go example um you know it it every day at 2 a.m it does some query uh does some api call querying the word dog and then on the back end um you'reing that. Maybe there's some way to know, hey, this is a test query. And so when you pass that flag, it starts, you're keeping track of a lot more than it would otherwise. And it says, you know, it makes sure, hey, you know, did you get it? Did anything, you know, get returned back? You know, maybe if there's no results or it never actually returned anything sure, hey, did anything get returned back? Maybe if there's no results or it never actually returned anything because it crashed or something like that, then it would send an email

to some developer and say, hey, the dog query failed today. And that person would know rather than having to wait until they get reports from real people who are trying to use it. Yep, yep. That's how you should actually do it, because otherwise you have to get up in the middle of the night and have had those experiences. So, yeah.

Yeah. You should always tend towards automation. Cool. Yeah, that makes sense. What about throughput? What happens when someone has just one machine That's servicing a request And all of a sudden they start hitting 1,000 QPS Or 10,000 QPS or something like that Kind of walk people through that sort of nightmare scenario

And how they can sort of recover from that. I mean, in a way, it's a first world problem. It's like, imagine you have some web service that's part of some product, and all of a sudden you get featured number one on Hacker News, and your web service just crashes down to the ground. How do you sort of handle that? So, I mean, I would say if you get featured on Hacker News and your service is getting popular,

it's kind of a good problem to have. And in some ways, you can preempt that by load testing your service or kind of just making or simulating that scenario yourself. So that's what we recommend to a lot of people. Without really waiting for that, I think you would want to

do some levels of simulation before you deploy. In my experience, what we have seen is that as a service becomes more and more mature, you layer the service with different tools. And they help you take in that load, distribute it across different servers, and make sure that the load is not on one specific server.

It happens over time, but let's say you start with a very simple application, maybe taking the DuckDuckDuck example that you had there. In the initial phase, one person is sending the service and it grows for a bit. A few hundred people are using the service. In most scenarios, you will be fine. Whatever you set up on AWS is going to be good enough to take that load.

But as your usage starts kind of growing, you would probably want to make sure that it's not just one server that's taking that load. You might want to put a load balancer before it. And instead of deploying your service on one server that's taking that load. You might want to put a load balancer before it. And instead of deploying your service on one server, you deploy on multiple servers. And what a load balancer does for you is kind of distribute the load according to an algorithm.

And it makes sure that your service kind of doesn't go down, right? So it takes in the service redirect redirects it to a particular... Sorry, it takes in an API call that comes into your service and distributes it to a particular server. The server does its job and returns the response. If the server gets full, it would send it to another server, and it kind of goes on.

So it really helps you kind of add more servers and load balancers do like a very simple job of routing. So they can take in a lot of requests. So the load balancer, is that something that you have to really, there's probably like a, it's probably generic, right? So it's probably,

you can just use something open source or something commercially available and it would probably handle almost every use case or do you have to write something yourself? No, most of these things are available. Lots of options actually are available to load balancers. I think AWS has something pre-built and if you don't want to use that, I don't remember exactly what technology we use, but yeah, you can get something pre-built. And if you don't want to use that, I don't remember exactly what technology we use,

but yeah, you can get something pre-built from AWS, or you can pick up something from the open source world and use it. You don't have to write a load balancer yourself. Got it. That makes sense. So you talked a little bit about simulating events, like simulating what happens if I double my user base and things like that. Can you dive into a little more detail there? Like, how do you actually simulate? It just seems like such a chaotic system, right? We have people all over the world trying to access something and then that volume of people kind of double. Like, how can you, you know, kind of simulate, how can you prepare for something like that? So I can kind of explain it from the perspective of Postman. We kind of looked at solving this

problem while building the product. So Postman lets you send like a request one at a time, so you've built your service and you're sending requests one at a time. What Postman lets you do, and other tools also let you do that, is automate this sending process. So what you want to do is write out a scenario. So in most cases, your users will be going through certain flows in your application, right? Or in your web service. So they might be hitting like, you know, a few calls in a particular sequence. And the way most developers test stuff is that they're going to hit them one after the other.

And they'll be like, you know, yeah, that's done because it kind of works this way. But what happens when your service starts getting a lot of traffic and it has to scale up, basically this activity is happening several hundred times in a minute. So what you would want to do is package this up. In the case of Postman, you can build a collection. That's Postman's abstraction for grouping together API requests. And you can run it in one go using a tool that we provide called Collection Runner. So you can just run it in sequence and essentially simulate the scenario of sending one request after the other.

What the Collection Runner also lets you do is it lets you run it across several iterations. So very quickly it can send these requests one after the other and you would get some basic sanity in your simulation scenario. Now we also have tools

that let you kind of export this collection out, and you can run it using an open source tool that we provide using the terminal, and you can run multiple iterations of this, and you can run them in parallel. So we're not very sophisticated there. You have to kind of do some basic work there, but once this scenario kind of works for you and you have tested it across this debugging process

and then through some lightweight automation process, you can use a more professional load testing tool that's going to run this scenario over and over again. And it can simulate, like a more professional load testing tool can send requests from different locations. So just think of these calls being made from places around the world. And once you kind of do that, then what you might start seeing in your server logs or kind of in your monitoring service is that the server starts behaving differently

than what you started out with, right? So when you start out building something, you have the most pristine kind of assumptions of the service. But as this load testing system starts putting pressure on the server, your service might start behaving a little bit erratically, And you might notice issues of state, you might notice things kind of not working well

between the server and between, you know, the application that is supposed to kind of receive the data. So lots of things can go wrong. And, you know, so it's basically a progression of things one after the other. And, yeah, you know, we would typically recommend doing this before, you know, you get featured on Hacker News. Right, that makes sense. And that makes sense. So basically, if I have a decent user base, but I'm going to have this big, I'm going to be at a NVIDIA GTC or something, which is a big convention. Then I can combine Postman with one of these professional tool, professional load balancing or I guess professional distributed pinging type tools

where they'll make a bunch of requests and all of a sudden it will feel like I have twice as many users, but half of them are fake. They're just kind of doing random things on your service, like making random queries, but at least it's making sure that you have the throughput so that when you go to that big conference, you turn that thing off and

hopefully that gets replaced with real people and it continues to behave well. Absolutely, yeah. So on this side, you would have like load testing tools. On the other side, from the perspective of the service, you'd probably have load balancers and a fleet of servers ready to go. So you can, you know, kind of like make changes without like bringing down the service. So yeah, you know, this setup typically works for most cases. I'm guessing if, of course, if you're Google or, you know, Facebook

or, you know, a large large company that has millions of users, this setup will be much more sophisticated in its complexity. But if you're a developer or you're a startup starting out, this would take you through a long way. That makes sense. So when you have an actual website, there's this concept or there's this technology called cookies, which basically means you sign some information on the browser. Then some encrypted data goes to the server. And basically the server has the, I'm trying to figure out a way to explain this really quickly, but let's just say the server has access to some data.

The server can pass that to the browser, and the browser doesn't actually really know what it is. But the browser can pass it back to the server, and then the server can decrypt it and say, okay, this is sort of some state information. And so through the cookies, the server can... So for example, if you were to... And I don't know if this is actually...

Patrick, you can correct me on this. But I mean, if someone was to actually take the cookies off of your computer, they could probably log in as you on a website because that cookie is sort of... you know, when it gets to the server, it's telling the server that the server is going to unpack that cookie and then realize, okay, this person has already logged in, you know, five minutes ago. And so they're authenticated, right? And so what is, is there, you know, when you're building web services, is there a concept of state and how does that work? Do you still do cookies in a web service or is it done through some kind of token or something like that?

Yeah, so cookies are still used in authentication mechanisms in web services. In my view, they don't give the best experience to the developer because your web service is going to be consumed outside the browser. So what essentially kind of happens in this interaction is that the server basically expects that, okay, there is some piece of identifying information when a call comes in to me. And when a service is being called through a browser, a lot of this can be hidden behind the scene,

like the cookie mechanism takes care of it. And wherever, if you're using an existing language framework, a lot of them take care of this for you. So if you have built a web service and you're using a language framework like Slim for PHP or I guess Ruby on Rails or something, then it will automatically kind of do it for you. But this can, like consuming the service becomes harder when you are doing it outside of the browser. So if you are kind of writing your own API client

and you want to make a call to that server, typically servers support a token mechanism or they would support one of these authorization authentication protocols like WOT1, Basic Auth, or WOT2. There are lots of these available. And what they help you do is kind of provide a scheme through which you can say that, okay, I'm a valid user of this particular API call. And there are some optimizations you can make with these systems.

So let's say if you're using a watch tool, you would have to be registered with a service and then you're going to get one kind of a token and then you're going to exchange this token with another token. And then finally, you are in an environment where you can make calls. But it's your responsibility to kind of keep the token

unlike the cookie mechanism where the browser does it for you. In this case, you would have to keep the token and manage the state of the token. And in some cases, the server might say that the token is not valid anymore. More complex authentication schemes manage that. But in some cases, like basic auth, you can essentially generate a token and send it for a successful API call until the

password changes. So when you move from building web services for browsers to web services that have to be consumed in a wide variety of settings, you might want to adopt some of these more kind of protocols that are more suited for this kind of authentication. Okay, that makes sense. Yeah. So basically, you would have one endpoint in your web service that's, you know, log in, and it would take the username and password, and it would return back some token, some really large number. And then once the person has done that, then the next time they try to call something else, like, you know, give me all the search results for dog or something like that, they would pass in that large number that you gave them in the first call.

And that person would, their receiver would then assume that that person is good for a certain amount of time or something like that. And I'm sure it's more sophisticated than that, but at a high level. Yeah, I mean, API security or like web service security security is a big topic. And as with scaling up services, it kind of gets more and more sophisticated because it depends on, again, on the context in which the web service is being used. But what I would recommend every developer to do

from the get-go is keep this consideration in mind. Because if you don't, if you think of this, when you've gone to production, you know, maybe if you're featured on Hacker News, you know, somebody might be trying to get into your service. And they might not have the best of intentions. Yeah, that makes sense. Also, it's, yeah, it's really important to, this is just in general to use libraries and and to look at sort of the standard way of doing things i uh i built a a website a really long time ago and i did this uh authentication type thing with um the one i just described which is like very primitive but i put the token in the, as a query parameter,

like I put it in the URL. And so what happened is people went to my website and they said, oh, this is really cool. And they copied the URL and sent it to their friend. And they didn't know that they were actually sending their friend the token. So when their friend went to the website, their friend all of a sudden was logged in as

as that person like uh and so that's an example of just you know i had no idea what i was doing and i made something that was just completely insecure and so yeah you definitely want to um you know use a lot of these like oauth2 and things like that i mean they've gone through and i remember when i integrated oauth2 i thought like that i mean they've gone through and i remember when i integrated oauth2 i thought oh this is really strange that they're they're sort of having me jump through all these hoops um but then in hindsight it was oh yeah that's because when you don't do this other people just get everyone else's password so when it comes to security um and this is true for everything even if you need to encrypt, you know, a chunk of data in memory or something like that, you know, use LibSodium, use LibCrypto or Gcrypt.

You know, don't write your own AES or Blowfish or your own encryption algorithm. And just anything with respect to security, it's so, so important to use, you know, off the shelf products and Postman probably integrates with almost all of them. Yeah, that's right. Actually, you know, Postman can help you do the opposite. Like it can help you break into stuff or you can help you test for whether you're, you know, making a common mistake. So kind of going off that example that you mentioned that, you know, if you put something inside the query parameter, you know, it's going to be copied. It's more visible there and, you know, people will copy and send it to people. And of course, that's a breach of kind

of security. One of the more interesting things, and this is something that we have seen in production scenarios, where people will put something inside an HTTP header and they'll think that, okay, this is not seen by the user, right? They only see the URL. So maybe I'm safe like that. And they will put some sensitive token inside the HTTP header. And your HTTP header can be inspected by Chrome's network inspector, or we have an extension called the Postman Interceptor, which can capture calls and send it off to Postman. And it kind of captures the entire HTTP packet, which is basically your web service call.

And you can see the entire set of things that are being sent from the server. And if your API security is not proper, then you can actually extract things from the header. Lots of interesting ways I think I've seen people use stuff. But you can use Postman for just a basic sanity check on whether your server is returning something sensitive, which you don't intend to.

And yeah, it can reveal some surprises yeah that makes sense i mean you could have a list of postman uh you know fake accounts on your website and uh if if the postman service logs in as somebody else you know that something's gone horribly wrong yeah yeah absolutely what about so, you know, if you do mobile development or even web development, there's this concept called gremlins. And so actually, if you're out there and you're a mobile or web developer and you haven't used gremlins, you should check it out. It's really, really fun. I've used it a lot on web. I know it exists on mobile, but i haven't tried it there

but but uh for web there's i think gremlins.js and what it will do is it will literally um do random things on your website so in other words it will click on random places in your website um it will just type keys it'll click and type keys and then click somewhere else. And just like it has no rhyme or reason. And what you'll find is that it will break your website. Like, you know, because you have sort of an assumption in mind of how your website's going to flow. And then this thing just doesn't care.

Like it will just type anywhere. It will type in the search bar. And then while you have, you know, the prefix search coming up, it will try to log in. And your website will just fail in spectacular ways. The other thing it can do for web, which is particularly sinister, and a lot of people don't even bother protecting against this. But, you know, on the web, there's really nothing stopping someone from clicking buttons that are hidden right just because you have a button hidden uh hidden is really just a little you know notation in the html the button is still there the the code is still there and people can click buttons that aren't visible um and so this gremlins thing has an option where you can turn on, which gets really

aggressive and it will try to, you know, unhide things and click them. And most websites break with that. Is there something similar in Postman where it just does like basically a Monte Carlo and just tries all sorts of crazy API calls and sees if it can crash the endpoint? So it's not kind of pre-baked in, but you can build that in Postman. So Postman has a runtime built in that is basically built on top of JavaScript. And what you can do actually is attach JavaScript calls, JavaScript scripts, JS scripts before and after your API calls. So think of it as a sequence of stuff. You know, first one script runs, then you make your API call, and then another script runs. And this script, which we call a test script, can essentially analyze the response that is returned from that web service. So what a Postman collection, which is the thing that stores all this stuff, can do is just help you script any scenario.

So you can do things like go one after the other, or you could change the flow of how the collection will be run and go in random directions. Or you can inject different kinds of data into the web service. So one of the most common ways to break a web service is to inject very large strings into the API call. And you wouldn't want to kind of type that stuff here manually. You can just write that in the script that runs before the web service call.

And, you know, you can generate kind of fake data or there are interesting attacks that you can do for the service, which, you know, would probably want, you would want to make the server emit some sensitive data, for example. So you can do all of that with Postman using the scripting runtime that's there. And it's built on JavaScript. So it's kind of pretty simple and

easy to use. So you can do lots of interesting things there. And yeah, you could run it as a kiosk monkey kind of a thing too. Yeah. Oh, yeah. That's another word for that. How do you prevent something like that? I mean, let's say, you know, so on the browser, you can log in with a username and password, right? And the browser, maybe if you type in a really long username, there's a check on the browser, some JavaScript that runs on the browser. It says, hey, your username can't be this long. But someone can easily just bypass that and they can make a call directly to your web service with a username that's, you know, 13 megabytes long or something like that. Yeah.

What is the defense against that? So, I mean, I guess the first rule that you have to follow is don't rely on client-side testing. So don't expect that, you know, that JavaScript test that you have on the client side or in your app is going to prevent it. You have to write checks on the server side. So in your server code, typically this features in terms of sanitizers that run before you actually process any data that comes in from a user. So one rule that you could follow is just don't trust user data. The moment you kind of put a form out there

and there is a field in which somebody can put in something, just expect that there is going to be something malicious. And then you check for how you are processing that data. The moment it kind of hits your server and it goes to your application framework, you would want to make sure that you sanitize it. I'm sure there are tons of libraries available to help you do that.

So just like the way you don't have to roll your own crypto library, you can use something that's available in the open source world and use it to sanitize your data. And finally, when you work with user input, you kind of make sure that you have checked for some of these things.

So a lot of this can be automated. Some of this is just basic kind of awareness that you might want to have, making sure that any interface that you expose to the outside world will probably be hit with malicious data. And once you work with that assumption and you chart out how this data is kind of flowing through your service kind of processing systems, you can take actions against it. In some cases, just adopt a library, or in other cases, just kind of, you know, make sure you have some basic checks in place. Gotcha, that makes sense.

Is there like, my guess is there's probably, I don't know much about the HTTP protocol, but it probably has some maximum, I guess, like packet size or request size built in. So someone couldn't put in like a 400 megabyte username or something like that. At some point, I guess the protocol itself would stop that, right? Yeah, I think the protocol prevents it, prevents that sort of stuff against like query parameters or URL characters.

Where things can get a little hairy is when you have request bodies. Request bodies could be arbitrarily large and I think that buffer overflow attacks and things like that. So if you have like in most servers, the server will process the request and might just ignore the body altogether. So you don't have to worry about that. And it would have those checks, which are protocol driven for what is coming in as an input on query parameters or headers, though you can do something malicious with that too, I'm sure. But when it comes to bodies, I think, I don't think the protocol specifies a higher limit. Oh, I see.

We have seen feature requests where people are like, yeah, I have like, you know, this crazy file that I need to upload. And, you know, on the client side, we run out of memory to process that request. But I guess the protocol allows for arbitrary large stuff. Oh, I see.

And so early on in the server, while you're reading this TCP stream at a really low level, you say, okay, you know, either the header says that this body is going, okay, you know, either the header says that this body is going to be, you know, a gigabyte, so I just forget about it. Or, you know, I've read 10 megabytes, and there's no way a username is even close to that. So I just drop the rest of the packet and close that request or something. Yeah, I guess I mean, I guess these

checks would be built in, you know, Apache or Nginx, which I'm checks would be built in Apache or Nginx, which I'm guessing would be the more common options you'd be using at the server level. Yeah, it makes sense. Yeah, I guess the server request size is not something we've seen a problem, because people are not rolling off their own servers. The tricky part is always in user input validation.

That's the one that trips up a lot of people, like, you know, a non-sanitized input or something like an XSS attack where people put in like JavaScript and you kind of store the JavaScript in your database and you render it as it is back into your web page. And that can essentially reveal your cookies so the more can you can you dive in detail on that that uh that went over my head so so the idea is you make a username that is javascript and then when the server yeah can you run that by me again yeah sure so basically let's say you have uh come you have no sanitization on what a user will enter in. Let's say you have a sign-up form and you're asking for somebody's name.

And somebody enters in a bunch of JavaScript in there. And what you have on the next page is that this name is going to be displayed after somebody submits the form. So somebody puts in some JavaScript code in there. This goes to your web service, and you're like, yeah, I love my users. I trust my users, I'm going to put this into the database. And when you go to the next page, you pick up the same value.

And in some ways, this thing can be crafted in a way that this piece of data will execute in the browser, right? And what happens is, I think this is called an excesses attack. Yeah, cross-site scripting attack. Yeah, right. So when this JavaScript executes, you know, depending on what the way it's crafted, it can reveal some sensitive information to the attacker.

Oh, I see. I see. So basically, like, so so yeah, so you have, you know, a spot in your HTML for the person's name, and then you're just going to take the name out of the database and just drop it in that spot in the web page. Maybe it's in the top right or something like that. And what someone's done is they've made their name, you know, start JavaScript, you know, you know, look at all the cookies, convert them to plain text, send them to my server in Russia and JavaScript. That's the person's username. And then when that name gets, you know, displayed on the top right, boom, that executes. Cool. Yep. Yeah, that, that, that executes. Cool. Yep.

Yeah, that sounds pretty dangerous. Yeah, I think a lot of that, Postman could probably help with a lot of that because my guess is you could do some checks to make sure that data is, if the person says, yeah, maybe you could go into more detail on how that works like do people give you a spec and then you find if there's a way for you to violate that spec like how do people use postman to do to to verify that their validation is correct so the way it works in postman is uh is you would write a validation script for this. So Postman is a pretty kind of flexible tool.

We don't, like it's not specifically built for this use case, but we kind of give you the interface to kind of send API calls. And then you have this runtime that kind of executes these validations, you know, once you're going to receive the response. So, and then you can automate the process. Oh, I see. So you have like a postman automatic request where every day at 2 a.m., someone tries to make a username called, you know, get all cookies.

And every day that request fails. And the one day it doesn't fail, we get an email saying, hey, somebody, you know somebody made the site insecure. Yes. So in a nutshell, it would kind of work like that. You would have to go through a bunch of steps, like you would build a collection, you would write your web service call, and then you would test for this specific thing. You would run it manually, and then you would automate it as part of your test suite. And then you can set up a postman monitor, which will run this test against your service.

So in the future, let's say you make, somebody makes a mistake, you know, somebody comments something out, and this test kind of fails. Then you're going to get an email saying that, hey, you know, something's kind of wrong with your service, and a validation that you set in place is not working anymore. The way we've kind of built the product is that it doesn't have to come to a point where you deploy something kind of wrong in production. You can catch it either manually or if you're doing your automation test suite, you're running it regularly. So typically you would catch it early on. And, you know, in the worst case scenario, of course, you know, you can set up a monitor and the monitor would have to alert you.

Oh, that makes sense. So you have like a canary version of your web service and Postman's the only person using that. And if you find some error, then it won't roll your canary into the production version. Exactly right. So the way we have seen systems to, or web service deployments to kind of go is people have a development environment that runs on your system.

So you are writing code in your ID and you have all of this configured on your local system. So you basically are developing on local host. And then you have a staging environment where your team is kind of working together and deploying kind of all your web services and putting them together in one place. And that kind of acts as a check before you go

to production. And then finally, you have the production environment, which is what your users are seeing. So in Postman, actually, we have a pretty cool feature called environments that helps you take out parts of your request and convert them to variables. And you define those variables in these environments. So you could have a development environment, a staging environment, and a production environment. And each of these environments will have different values for the variables you set.

So you can set, if you set the staging environment in Postman, all the calls that you are sending in Postman will now go to the staging environment. Or if you set the staging environment in Postman, all the calls that you are sending in Postman will now go to the staging environment, right? Or if you're running a monitor and you set the environment as production, all the calls will go to the production environment. So Postman kind of makes it very easy

for you to kind of work across different environments. And this is the typical setup that we have seen, kind of like a three-stage thing. In some cases, it's more extensive. I think I've seen environments where there are seven different kinds of stages. But yeah, we kind of saw that and we built that into a feature called literally environments in Postman. Yeah, that makes sense. So what about in terms of the product, what's the pricing?

How does Postman actually work from a product perspective or business development perspective? You charge per endpoint, or how does that work? So Postman is free for everybody to download and use for making calls. So there is no restriction on the number of calls that you can send because it kind of runs as an application on your machine

and you make the calls on your network. So you can just download Postman and use it as much as you want. Oh, cool. Is it open source or is it, like, how does that work? So all the core components of Postman are open source. The application itself, like the desktop application, is not open source, but the runtime and the collection format, a bunch of SDKs are all open source. Got it. a request very simply, which is basically sending an API call and returning a fixed response. You get that once you sign up. You can generate a documentation web page

through Postman, which will run in your browser. It's not tied to the app anymore. You can set up these monitors, and we'll make calls for you to make sure everything's working with your web service. All of this stuff is also free up till a particular point.

So you can make, for example, 1,000 calls through Postman monitors in a month. And then after a month, this will renew. So this is typically good for small projects, proof of concept things. And if you want to access more of this stuff, then you can become a pro user of Postman. And that is at $8 per user per month. if you want to access more of this stuff, then you can become a pro user of Forceman. And that is at $8 per user per month. And you get a lot more of these advanced tools. And for our enterprise product, which is more tuned towards larger companies, the price is higher. For developers, yeah, you would be on pro. Cool. So if someone wants to

you know someone's in their dorm room and they've built something which uh returns basketball scores or something like that um they can use postman totally free i mean they're probably not going to hit the thousand query limit definitely not you know right away and um and uh yeah they would be set for a while with uh just the free package and then if all of a sudden their site becomes more popular than nba.com then they have all the infrastructure in place and they can scale up yeah i mean i'm guessing if if you are at that level then probably you're paying for other things a lot more than you'd be paying for postman yeah but yeah you know you can use it for as long as you want

for lots of interesting stuff. You can build lots of interesting things in Postman for free. We have now more than 5 million users across the globe now. Postman is used in a lot of university courses as part of boot camps and programming classes and stuff. And we are actively supporting that. So it's very exciting for us to see the product being used in essentially helping developers learn about APIs and web services.

Cool. Yeah, that's super, super cool. So tell us a little bit about the company. So what's it like, you know, working at Postman? Where are you located? What's your, you know, office like? Are you hiring? These kind of things. There's a lot of people listening out there who are either looking for a job or they're, you know, they're in a university, which means they're almost certainly going to be looking for a job in the next few years and give them kind of a taste of what it's like to work at Postman and what opportunities there are. Sure thing. Yeah. So we started as a startup in 2014 and we've been growing pretty rapidly since then. We have an office in San Francisco and we have an office in Bangalore.

And we are hiring for lots of different roles. We have kind of a marketing and customer success teams here in San Francisco. We have our developer evangelists here as well. Our engineering team is in Bangalore as well as our design team. And I think now we are more than 50 people. So what is that? Can you just tell people really quick what's a developer evangelist? A lot of people might not know what that is.

Sure, yeah. So developer evangelists for us, now traditionally developer evangelists basically try to kind of weave in or they try to kind of explain a company's technology to other developers. They build interesting use cases for, let's say, the technology that the company has built on its own. But they also talk about open source tools and technologies and how things kind of fit together.

And their job essentially is to make developers make the best use of components that are available in the developer ecosystem. So it's a lot of education. It's a lot of teaching, a lot of coding as well, where you would probably be building plugins or integrations with different technologies to kind of illustrate kind of new and cool use cases. You might be presenting at conferences or meetups that's what our developer evangelists do they kind of you know organize our meetup and tell people about you know interesting things that they could do with postman so it's a very uh it's i'd say it's a relatively kind of new role for uh the wider kind of startup ecosystem. Companies like, I guess, the bigger companies like Microsoft and Google have more professional programs. But, you know, now you can actually work as a developer evangelist

in a lot of startups and midsize companies. Cool. That makes sense. And so you mentioned you're in the city. So you're in maybe like a high-rise and Soma or something like that? Yeah, so we recently moved to a new office. Cool. And it's on Market Street, on 2nd and Market. Okay, cool.

We literally started in the basement in SF. We started in a co-working place, then we moved one level up to the second floor, and now we are on the 11th floor. Nice. So, yeah, as Postman has been growing, we're kind of moving up. Yeah, literally moving on up. Yeah. Very cool. Well, yeah, this has been really fascinating.

I mean, as I said, I made a fool out of myself building a website a while back and uh yeah i still uh i've learned a lot over the years but one of the biggest things i learned is to rely heavily on you know services and that allows the developer to really focus on the bigger picture which is you know tied to whatever they're they're trying to build and however they're trying to improve um you know, whatever kind of product space or human condition or whatever they're focused on. And so, yeah, this is another great tool. And the really nice thing about this service, this product you've built, is that, you know,

it sounds very accessible. Anyone can really get started using it. People, a lot of people are now using web services for almost anything. A lot of these things, like, remember, Patrick, remember, what was it called, the thing that was kind of, I want to say it was like Corba or something like that. That is a thing, yes. But there were these, like, uh other before web services really took over

there was yeah soap was one of them and there was these other ones where um yeah yeah rpcs yeah i mean at least you could call like uh you know grpc and uh you know thrift and these kind of things put them in that category although they're still around um but but now pretty much everything has moved on to web services. And so there's probably a bunch of people out there who have built web services as an accessory to an app that they're working on or a website that they're working on. And they could plug right into Postman for free

and make sure that what they're building is kind of solid, which is really cool. Yeah, absolutely. Thank you. Glad you like the use case. We started, like actually we have a stronger kind of hypothesis, what we kind of started seeing from talking to our users, that a lot of ways in which they're primarily

developing actually driven through web services you know you have lots of interesting apis available now uh which you can just kind of drop in and call and you know you don't have to think about like every little detail um you know you can for example use stripe and you can get like in a very powerful like payments platform working for you you can you know cause it you can call aws s3 api and then you kind of get a very powerful like storage api and i really like this three api because kind of really small and kind of does so much for you so what we kind of started seeing was that you know the way you will build software of course you have all of these other ways in which you will be writing code and compiling code and building

the more traditional application, but that application is always either going to be using APIs or might be just composed of APIs. So, yeah, we're pretty excited about this whole thing because, first of all, it's very accessible.

You have to use... I mean, these are all built of HTTP, so it's pretty easy for you to use in any language, any framework, any which way that you want to use it. And it's super easy to kind of get started. You don't have to download thousands of dependencies or understand a very complicated language, maybe like Carver or something like that. Like, and that's really kind of helping

this whole ecosystem grow very quickly. And any conference that you kind of go to, like every company kind of has an API out there. It's kind of becoming more of a prerequisite that you have APIs so that developers can build something more interesting. And, you know, they just don't have, like, people who are users of your product don't just have to depend on, you know, just what you provide out of the box.

So, yeah, it's a great time to kind of be a developer, you know, and build cool stuff. Yeah, definitely. You know, one thing that I really didn't understand early on as a developer was how to really combine languages. So, for example, you might find this really great library on GitHub, some open source library for, let's say you're making a poker app. And you find a really great library for telling you the hand. So, in other words, you just give it the seven cards. If you're playing five card stud or something, right, you give it, you give it your, your set of cards and

it will tell you, Oh, you have a pair or you have a full house or you have a flush or something like that. And so someone wrote some really great code to do that on GitHub, but it's in, I don't know, go the go language and you've written, you know written your whole poker backend service in Java, right? Also, you can do things like Swig and things like that, but it gets ugly really quick. Like trying to call one language from another. I mean, I've done it before. It's not pretty.

You really don't want to do that and so what you ultimately what you want to do is wrap that you know poker hand evaluator in some type of web service or some type of service and then have you know your Java code call into that even though it's on the same machine you know have your Java code call you know access you know local host your Java code call, you know, access, you know, local host port, port 70 or something and, you know, pass in some poker hands and get back some scores. That might be easier than either having Java go through JNI to talk to Go, which is kind of a

nightmare, or rewriting this entire open source library in another language, right? Right, absolutely agree. So that's a recurring challenge kind of in reusing software functionality, right, everywhere. So in some cases, things work out. You might find the library that you want in your language. But when you build things off in a web service, you can consume it kind of anywhere. There is that additional overhead of kind of running the service, but it's typically small in the long run. The more interesting kind of aspect that I'm very excited about is when you kind of build a web service and you have it operate pretty reliably and robustly,

then you can actually really build larger and larger pieces of your software pretty easily. You know that this piece is going to stay this way and you have abstracted out all of its internal concerns. Maybe next time you actually do want to write that thing in Java, but the things that depend on that web service only talk HTTP. So you can really change the internals of your web service and write it in a new way if you want to make it more performant in any other language. But as the interface is set in HTTP, you don't have to cause a disruption in pieces of software that consume that service. So really, I feel like it's a nicer, cleaner abstraction for building, you know, larger pieces of functionality. And we are seeing that with, you know, kind of organizations adopting things like microservices or really using, you know, small APIs kind of glued together rather than just going completely

off, you know, big pieces of software, monolithic packages, if you may. Yeah, totally makes sense. Cool. Yeah, thanks again for coming on the show. Fascinating, I think. Oh, let me give you a chance to tell everyone, how can they get to the website? And also what social networks you're kind of most active on

so that if they want to get started, where should they go for that? Sure thing, yeah. So we are at getpostman.com. So it's super easy to think about. Get and post actually are the first two HTTP works which you will use in building your web service. So yeah, think of that. And it's getpostman.comcom and that's where actually the name

postman also kind of comes from uh post stuff and uh yeah we are on twitter that's where we are most active uh my twitter id is a85 a85 so three characters and uh we are at Postman Client for our official Twitter ID. Cool. Your Twitter handle is A85? Yeah. Wow. A three-letter Twitter handle. That's pretty cool. I've been registering for these services very early on. Oh, yeah.

That's super impressive. Yeah. Very cool. All right. Well, thank you again. And yeah, people know how to reach you it's only three letters on twitter folks so if you have any questions for happen off just go for it cool thanks a lot well thank you so much

Jason thank you so much Patrick the intro music is Axo by Binar Pilot. Programming Throwdown is distributed under a Creative Commons Attribution Sharealike 2.0 license. You're free to share, copy, distribute, transmit the work, to remix, adapt the work, but you must provide attribution to Patrick and I and sharealike in kind.