Python Bytes - #52 Call your APIs with uplink and test them in the tavern

Episode Date: November 16, 2017

Topics covered in this episode: Restful API testing with Tavern Uplink Using json-schema for REST API endpoint tests Live coding to music! Weekly Python Chat 10 common beginner mistakes in Python Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/52

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 52, recorded November 15th, 2017. I'm Michael Kennedy. And I'm Brian Ocken. And we got some awesome news for you. But hey, Brian, just want to say happy birthday, man. Oh, yeah. Happy birthday.

Yeah. So this is the 52nd episode of Python Bytes. And if I recall, I don't think we skipped. I'm pretty sure we did not skip a single episode. We shipped the entire first year. We shipped an episode every week. And I think that's pretty awesome. That is cool.

Even around Christmas and stuff? Yeah. I think we somehow recorded ahead or I don't know. Maybe we missed one, but I think we did it. Okay. So pretty exciting.

You know, and I just want to say thank you to everybody out there who listens to the show on a weekly basis. That's why we do it. We do it for you guys and we wouldn't do it if you weren't interested and excited. So thank you for

appreciating this, giving us all the ideas and keeping us going. Yeah, definitely. Thank you. And we had a whole bunch backed up. So this episode is two hours long and it has 52 topics. That's right. So you guys deposit now, get a coffee, settle in or whiskey if it's late. Now, actually, we're going to keep to the same format. All right, cool. So before we get to our topics, though, I just want to say thank you again to Digital Ocean as well. They're another reason that this show is going strong. Digital Ocean, Rollbar, and a few of the other folks that continuously support the show.

Thank you. Thank you. They just launched Spaces. Check it out at do.co slash Python. Tell you more about it later. Right now, I want to spend a while on APIs, Brian. Yeah, I've got APIs on the brain right now. So we'll start with a new project.

I don't know if it's new, actually. A project called Tavern. It's like a drinking game or something? No, it's testing RESTful APIs. So I don't know why it's called Tavern. I'll have to ask him about that. It's a really cool project, though. I checked it out.

I like it a lot, actually. Yeah, so it's at taverntesting.github.io. Like I said, it's a RESTful API testing. And what it reminds me of the most is PyREST test because it uses a YAML format to describe the tests and describe what sequences to go through. So it does have like one-off tests where you could just either post or gets from a URL and then determines whether or not, and you can specify what you want out of it, but you can also do sequences.

And one of my favorite things about this is it comes with a PyTest plugin and they say it works best with integrated with PyTest. That's really awesome. So you basically describe, I want you to call this URL, it's going to be a get and you expect to get kind of this thing back and then you can just assert against it. Is that how it works? With the YAML syntax, you don't even have to specify asserts. You just specify what you expect to get back and it just automatically tests for all that. For things like this, actually, I really like, even though it takes up a lot of space, the YAML takes a lot more space than like a little test function, but it's very readable, especially if you have an editor that colorizes your YAML files. And I think it's good for,

especially you can discuss it with non programmer people. So that's one of the benefits of that. Okay. Yeah, that's really cool. Yeah, that's true. You can give a YAML file to a non-technical person who is like sort of a requirements gathering business analyst or something or domain expert. They can say, yeah, okay, these are the things that slot in here, right? Or to the person who built the API. Like for instance, the sequences, you can say, okay, here's the kind of the test is called this, and this is sort of the sequence we're going to go through.

First you log in, and then you have to do this. And there is also, with a lot of sequences, you have to collect, get information, like tokens or something from the server. And Tavern allows you to save those tokens as variable names to use later in later tests, which is nice. Yeah, that's really sweet.

That's Tavern. Tavern sounds really cool. Definitely worth checking out. The thing I want to talk about is not for testing APIs, but consuming APIs, calling APIs. What if you weren't looking at this document we're sharing, just like thinking of like, hey, I'm going to call an API from Python.

What library do you think you would use? Oh, request. Obviously, everyone uses request. And request is one of the absolute most popular libraries. It's downloaded an insane number of times. What I find myself doing a lot when I know this is like a proper API I'm going to consume. It's part of an application or I'm going to fold it in and make it really important is I'll create like a class, or some module that will model all the actions that you take against that API, right, like, log in, or, you know, get courses or whatever your API is about, right. And you sort

of put use request to implement it. But deep down, you know, you kind of bury requests. And hopefully you've got some like facade sort of class or module in front of it so i want to talk about this sort of up and coming project that does that all at once for you which is really sweet and it uses it with uh decorators called uplink have you heard of uplink not until you listed it today but it looks really cool it's super cool right so let me just describe like real quick how i use this. So imagine I want to call the GitHub API. I need to have a header on all my requests that says I'm using this particular format or schema for my JSON. I'm going to call the get users function.

I might update a user and so on. So what I do is I create a class, call it whatever you want, derived from a certain base class that comes from Uplink. I had to add headers decorator to the class. I say, except the right funky content type. And that just applies to all the functions you call on this class. If I want to get the users, I'd say create a function called get user. And I'd say at get slash users slash curly username. And that curly username there maps to the argument. So when I call it, I say, GitHub dot get user. Yeah, Mike C. Kennedy is my username there. And it actually directly

pulls that into the little URL in the decorator and passes it. Oh, this is cool. That is cool, right? And they have another example for updating a user that's a patch call. So you say at JSON at patch. And then the arguments to the method, can pass in just uh like a body of basically kw args and that becomes the body of the the patch submission you can also say access token colon query and use the type decorator in python 3 to decorate as a query so then it'll go question mark access token equals what you pass as that argument. This is so smooth. Wow. I really like it.

So if I'm building like a super structured API that's got really strict restful requirements like this, I'm definitely going to check out Uplink. I'm going to definitely watch this. This is neat. They have a little warning in there that says that it's in the early stages. But that might be a great way for other people to get involved if they want to help out and push this further. Absolutely. So that's definitely a warning way for other people to get involved if they want to help out and push this further. Absolutely.

So that's definitely a warning you want to be careful about. They say it's not quite production ready, mostly not because it doesn't work, but because they think the API may change. They don't want to break your code. So I think that there's an opportunity here. There are so many people that say, I really want to get started in open source. And they look at Django or CPython. I'm like, whoa, this is complicated. And changing this is really hard. Something like this, you could totally contribute to a project like this without getting overwhelmed in the early stages.

So check it out. Yeah, definitely. Cool. All right. So let's switch to a totally different topic and talk about REST and APIs. Yeah. Yeah. So I wanted actually to combine these two things because I ran across them in the same week for one. And this was shared by a listener. And I'm sorry that I didn't write down the name.

But yeah, thank you for submitting that. That's awesome. I saw that coming as well over email. There's an article called, I've got it turned around, using JSON schema, which I hadn't heard of before, using JSON schema for REST API endpoint testing. And the idea, had you heard of before using JSON schema for rest API endpoint testing. And the idea, had you heard of JSON schema before? I have heard of JSON schema. It's basically a way to say my, it's kind of like what your test does, but in a different level, you say, this is what the JSON is supposed to look like. This is supposed to be an integer. This is supposed to be a string and so on, but I haven't ever used it. So like I pretty much have exhausted my knowledge of it now.

The example of it, they do a Django, which I'm, I don't really know Django. So I kind of read that anyway, but I don't think that's necessary. I think you could use this for anything. But the idea is, you can implement a schema to describe what your data should look like, and then actually serve that within. So within your, on your server code, serve that as well. And then for your tests, you can grab the schema and then grab, grab whatever data you wanted and validate, use a test to validate that the data you're getting it adheres to the schema. And then you can also go out and make sure the values are correct and things like that. But actually, I'm just curious what you think of this. I think it's pretty cool, actually,

especially if the API already has a JSON schema associated with it. Right? Like if they're like, here's the schema, here's the API, then you could just, okay, and here's how I test, you know? One thing that might be interesting is like, it's interesting if you're the maintainer of that thing so that you know if the tests break that you're verifying, you have to go and update the documentation or something like this. But it's also interesting, I think,

to point it at APIs you depend upon and say, I'm going to call this and I want to know if the schema changes. Because it's totally common that people will document one API, the API will change, your stuff will stop working you're like but i'm doing what they say it's like you know what has happened right so if you knew the schema of why apis you depended upon changed this is a good way to do that i think that'd be great yeah or you could even i mean even if you didn't have a schema provided to you you could define one for yeah it's usually not too hard right actually that's a great idea and um another thought with that is that it's not just RESTful APIs.

Anything that's using JSON, you can use that to test any API. Yeah, definitely. It's very neat. So check that out as well. All right. Before we get on to the next thing, I want to tell you where your audio came from this week. It came from DigitalOcean Spaces. So that's right.

Those guys are sponsoring this episode, as I said at the top of the show. Check them out at do.co slash Python. Get a free two-month trial of Spaces. And Spaces is object storage and delivery in the cloud. You know, things like AWS or Azure Blob Storage. Sorry, AWS S3, Azure Blob Storage.

Things like that, but way, way better, better pricing, simpler things like this. So I've been using it for this podcast. I just recently, big announcement, switched to using it as the video delivery network for my courses. So I'm trying that out on a few courses and that's been super, super smooth as well. And what's really interesting, the way that I wrote the API for accessing the video files and stuff was I imported Boto3. That's the S3 AWS API.

So the API is compatible with S3, like quite literally. It's the same API, even just pointed at some different base URL and you're good to go. So if you've been using something like S3, you really owe it to yourself to check out Digital Ocean Spaces at do.to slash Python. Very cool stuff. Yeah, very neat. And cool that you tried that out, that the API is compatible. So far, it's working really well. I was thinking that some music could be nice.

I love to listen to music when I code. Do you? Yeah, all the time. It's funny. I find a little bit of distraction kind of helps keep the mind focused. I don't know. People are weird that way. I work in coffee shops as well, and I like that as well.

But this is a different kind of music to coding. So this is almost like music as performance art. So there's this presentation called Programming Music for Performance, Live Coding with FoxDot. This is by Ryan Kirkbride at PyCon UK. So this is a really short video, but maybe it'll inspire some people to do some similar performances. Basically, he's up there writing code to dramatic, part electric, classical type music. And it's just, it's really interesting to see it go. What did you think of it, Brian?

I thought it was really interesting, but I'm a little lost. So I was hoping you could explain to me what's going on. I wasn't at the talk. So the video is not that long. So I didn't see the introduction. But what I think it is, is it's like I'm going to show you some cool thing by writing a demo live and do it. But instead of explain it to you, I'm going to do it to a dramatic music and make it like a performance art. Remember how we talked about code is like poetry a while back. This is like code as performance art, I think. Yeah. I guess I'll have to check out what all Fox dot is and how that works with that.

Yeah. Yeah. There's not, sadly, there's not that much information in this, this video. Cause it's like partial and it's short, but this is from Ian Watt, another listener suggestion. And I thought it might inspire some of you guys out there. So I just, you know, short, have a look at this little video. it's like partial and it's short. But this is from Ian Watt, another listener suggestion. And I thought it might inspire some of you guys out there. So just, you know, short, have a look at this little video. It's cool. But be sure to turn on the audio. Plus he did a talk without speaking, which is good. Exactly. We've talked about, should you do live coding during your demos? This is like the

opposite of a, should I do live? It's like only live coding and there's nothing else. There's not even words. Yeah. Yeah. That's good. It's awesome. But if we had like a weekly Python chat, there'd be words, right? There would be words and video and audio. All right. So tell us about what you got going on this weekly Python chat.

I saw you were just on it, right? Yeah, yeah. So it was super fun. So weekly Python chat is at, how did he get that? It's at weeklypython.chat. But it's Trey Hunter and he's, he can't remember exactly what he does, but he's part of the Python Software Foundation, but he's also a Python instructor and he does quite a bit. He's a super nice guy. He has these weekly chats where he just picks somebody in the Python community and often requested by other people that listen and does like a little like a under an hour, approximately an hour video chat with somebody else.

But they're also you can do live coding. And then there's people in the chat room asking questions while it's going on. So it's a live thing. But then it's also recorded so you can watch old ones. So, yeah, the last one last week on November 9th was a testing Python with PyTest. So those with me, that's awesome. And I'm highlighting it because I want more. It's really cool. It's fun. It allows to ask questions of people that they wouldn't, maybe you don't go to conferences that much, but you could stay up for a weird hour or what, depending on your, where you live in the world, but you can ask questions to people you wouldn't get a chance to otherwise.

So that's good. Yeah. Very cool. Nice. So yeah, check that out. We got the link in the show notes. So let's run this out with a bunch of mistakes.

I think that's a good one. So our last topic is sort of, I think actually has a mistake in it. It's 10 common beginner mistakes in Python. So this comes to us from a blog post at checkio.org, or maybe better pulling up pi.checkio.org. Have you played with pi.checkio.org? It's like a video game for programming. I think I have. Yeah, I have. Yeah. Yeah, it's funky. So you basically give these little islands, you got to conquer the islands and you go the way you conquer them is by solving all the puzzles. It's a little bit like

Myst, but programming. One of the things i think is really cool about playing the game actually is you solve some little puzzle and then you see how everybody else solved it and then you get a see your style of programming relative to other solutions and it's kind of like code reviews because you can you can comment on other people's solutions and stuff yeah so it's pretty cool yeah so these guys wrote a blog post based on the mistakes they see people making from that area. They said 10 common beginner mistakes. Let's go through real quick. Incorrect

indentation tabs versus spaces. Obvious, but you can imagine if you come from Java that you don't know that, right? This one's more subtle. Using a mutable value as a default value. So like, you know, append to list and then you give it like source list equals bracket bracket as a default value. That is a super bad idea, but not at all obvious why it's bad.

Right? Because every time you call it without specifying that argument explicitly, it's going to use the same list because that is initialized at like, not quite compilation time, but as Python sees and determines that method, it finds that default value and sets it. It doesn't actually recompute it every call. Yeah, that's a fun one. Yeah, it's definitely fun and tricky.

Write a lot of comments in docstrings. You know, my theory is comments, not so much docstrings, but comments are deodorant for code smells and problems. So I'm not so sure I'm going to recommend that as much. But documentation, good stuff for sure. Scoping, you know, if you come from a C-based language with curly brace scoping, block scoping, Python is different with its functions, scoping and closures and whatnot. So that's definitely a mistake to be made.

One that I really love they covered is called edge cases first. And you could have like a loop with a test that does another loop with another test. And it could be some super indented thing, or you could do the negative test, the edge case that you're going to break out of, and then the loop, and then you're going to do the edge case you're going to break out of, and then the inner loop, and it's way less indented. And, you know, that's one of the Xenopython things, but also just a great design pattern. I mean, if you utilize, I see a lot of that when people are used to old style C code or something, that they don't trust the exception handling. Oftentimes,

you don't have to check for, you don't have to make things bulletproof if the function you're calling is going to check it for you anyway. Exactly. The easier to ask for forgiveness you don't have to make things bulletproof if the function you're calling is going to check it for you anyway. Exactly. The easier to ask for forgiveness than for permission style is better than the look before you leap. We got copying.

Everything is a pointer in Python. So the pointers means you may be sharing the same object, not a new one. So it talks about that, especially around the lists and data structures. Range is half closed. Range one to 10 actually is one to nine. Wrong capitalization.

So you're just writing like camel case, Java, C sharp style, or some JavaScript style of naming for variables, classes, functions, whatever. And then finally, using class variables incorrectly. This one's a little bit interesting about class level variables and inheritance. And you can check that out.

But they have nice little examples for all of them. And as far as I could tell, there's only nine mistakes. So I'm not sure what the 10th mistake is. But maybe I read it wrong. I read it twice. I didn't see it. So could be tired. Well, I mean, if the range is one to nine, if it's...

Yeah, that's true. It could be range one to ten common beginner mistakes in python yeah yeah perfect all right so anyway if you're getting started in python and you want to kind of level it up a little bit you know check that out or if you're working with new developers or mentoring new people this is all all good information yeah and also if you if you got somebody that works for you that's on check io at their lunch break they're not just goofing off they're upskilling so that's right let them goof off on check you that's on Check.io at their lunch break, they're not just goofing off, they're upskilling. That's right.

Let them goof off on Check.io. That's one of the best possible options. Beats Facebook every day. That's our six. Do you have any news for us? I do. I have two pieces of news or ideas I want to run by you. First, have you tried Firefox Quantum, the brand new Firefox that came out yesterday?

No. It's supposed to be twice as fast. A lot of it's rewritten in Rust. Use way less memory than Chrome. So these are all pretty exciting. So I'm actually checking out Firefox Quantum. I'm doing even the show from it this week. Pretty cool.

So yeah, if that sounds interesting to you, check it out. It sounds like Firefox might make a good comeback. And they're definitely the most open source friendly of all the browsers. So I love to see them like actually alive. Rust is that like that language that I always meaning, I'm always meaning to try to look at, but I haven't yet. Yeah. Well, it's getting dark and cold and rainy here in Portland. Maybe you have like a Sunday afternoon. You're like, you know, I just need to get a book and just sit by the fire. Yeah. And rain and rust go together really well. So they do. You can start with like some regular metal, put it outside. By the time you know rust, it'll be rust. It's all going to go together. well. They do. You can start with some regular metal, put it outside.

By the time you know rust, it'll be rust. It's all going to go together great. It's good. So the other thing I wanted to run by you is, by everybody, is how interested would people out there be in having an Amazon flash briefing that is this show? So what I'm talking about, if you don't have an Amazon Echo, there's a way to ask it in the morning.

You could ask it whenever, but I think the idea is in the morning. Like, hey, what's my news today while I'm brushing my teeth, getting ready for work, whatever, right? Or just sit down at my desk and I'm not really ready to work yet. You could ask for your flash briefing. And you can configure different sources like Reuters or NPR or whatever. And I was thinking it might be really fun if we took our little items and shipped one of them per day as a flash briefing. I think then every day somebody would have,

people would have a thing that we talk about for a couple of minutes for Python. Yeah, we should do that. Sound fun? So if people are super into this, send us an email or something on Twitter and let us know. Yeah, let us know. Yeah, if not, then I won't write it.

If we do it, then I can get an Amazon device as a business expense. Absolutely. I think that's totally great. Yeah. So the Echo Dot, just as functional as the full expensive one,

it's just the speakers aren't as good, but it's like 45, 50 bucks for one of those things. It's not outrageous. Yeah. And everybody's got them on sale

for the after Thanksgiving thing. Yeah, that's right. It's coming up. All right, cool. Well, that's all I have for us. Yeah, me too. Yeah. that's right. It's coming up. All right, cool. Well, that's all I have for us. Yeah, me too. Yeah, so just once again, thank you everybody for helping the show be one year old. It's really awesome. Yeah, thanks. Yep, and thanks

Brian. Catch you next time. Thank you for listening to Python Bytes. Follow the show on Twitter via at Python Bytes. That's Python Bytes as in B-Y-T-E-S. And get the full show notes at PythonBytes.fm. If you have a news item you want featured, just visit pythonbytes.fm and send it our way. We're always on the lookout for

sharing something cool. On behalf of myself and Brian Auchin, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.