APIs for Beginners - How to use an API (Full Course / Tutorial)

- Hello, I'm Craig, and I'm a developer. In this course we're gonna be exploring a term that you've probably heard quite a bit. That term is API, or Application Programming Interface. In addition to being able to recite what it stands for, when you complete this course, you'll be able to discuss what an API does, you'll understand why they exist, and you'll be able to list the many benefits that they provide. You'll even get some hands on experience using a few popular web API's which will give you a taste of what all this excitement is about.

We'll be starting from the very beginning so there really isn't too much I'm gonna be expecting you to know before starting this course. I would like to request that you have a touch of experience with coding, and a wee bit of knowledge about the web. If you've written any program at all, even the typical first program, you know the one where you write the words hello world? If you've done that in any programming language, you'll be pretty much ready for this course. It will be helpful for you to have a basic understanding of how the

web works with web servers, and browsers, but don't sweat it. We'll touch on this too. Now, if you haven't yet met these requirements, please check the notes attached to this video for where to get started with some beginning web, and programming concepts. Oh, that reminds me, you should probably take some time to get used to your learning environment. The notes that I just discussed are attached to this video. I'll also drop more information in that section to keep you updated on what might've changed from the time I recorded this. Now I'll do my best to

remind you to look in there when there's something that I think you just have to see, but you really should get in the habit of checking that area out. There'll be tons of juicy information there. Now these videos have captions, so if you feel like you might benefit from having those on, please use them. This space is all yours. If you want me to speak slower, use the speed controls to slow me down, and if you know, I'm taking too long of a time, just speed me up! I make a pretty good chipmunk, and last,

but certainly not least, take advantage of the fact that you are in a video based course. If you need me to repeat myself, use the video controls to rewind me. If you feel like you need a break to let something sink in, by all means, please pause me. I'll be right here waiting for you. I know that I've gotten into some bad video viewing habits with all the streaming media. Now, while binging might be a great way to consume an entire season of your favorite show, it's not the best way to learn something new. Education

isn't meant to be binged, and because of this I'll probably remind you quite a bit to take breaks, and encourage you to let what you just learned marinate. Alright, let's get to it. API, those three little letters generate quite the buzz, don't they? Now, first, I'd like to take some time upfront here to clearly break down what is meant by Application Programming Interface. By understanding its purpose, and a touch of its history, I think you'll start to see its importance, and begin to understand why this term keeps popping up in your life. After we get

a good grasp on the what, and the why of API's, we'll go, and learn how to explore to existing ones. We'll get familiar with a handy tool, Postman, which provides a nice way to interact with web-based APIs. We'll use that tool to hit an external web API to send actual text messages, and get some interesting data back from a streaming music service API. After some practice using the APIs, we'll insert them into a web application. The application we're going to be building is a web app called Complimenter. Our app will allow you to send compliments

to your friends, your families, and your colleagues over text message, and then it encourages them to visit your site, and do the same. Now I've included the final applications in both JavaScript, and Python, and together we'll walk through how to use external web APIs to solve the missing pieces. We're going to be strictly using APIs in this course. We won't be writing our own now. Well now you most likely will end up learning some best practices in API design, we won't be covering that specifically. There are many great courses available that show the creation thought

process, and I've linked to some of my faves in the notes attached to this video. In my opinion, the best way to start learning about any acronym is to focus on each individual letter. For API, I think we should start on the last character, the I, interface. Let's talk a bit about interfaces that you've seen already. Interfaces are all around us. For instance, this radio here, it has a familiar interface. The interface allows me to do things like change the volume, change the station, I can turn it off, and on. I literally have no idea

how anything inside this thing works, but still the interface allows me to control the way it works through the options that are exposed. The magic that is happening is completely abstracted away from me, and I'm still in control of what has been determined, that I, a user, can handle. Interfaces usually evolve over time, like an alarm clock radio for example. It has my familiar volume, and station controls, and it also adds some new features like changing the time, and setting the alarm. I still have no idea how this works implementation-wise, but the interface is something

that I can understand usually, and as technology evolves, and new options come into existence, they make their way into the new versions of the interface. Still abstracting away things for us, but enabling us to be in control of the new features. Sometimes these physical interfaces get so recognizable that they even make their way into GUIs. Did you hear that? There it is again, gooey, or GUI, Graphical User Interface. This is my streaming music app on my phone, and there's my familiar play button in the User Interface, or UI, and I know what that play button

does when I press it, but I have no idea how it does it, and I'm okay with that level of abstraction. I depend on it even. What would I do in public transit without music? Like talk to people? Hi, how's it going? Now the developer who wrote this streaming music application of course understands how the play button works. She coded the button so that when it gets clicked, the music starts playing. Here's the thing though. Our developer is also working with quite a few interfaces that are abstracting away some of the details for her. For

instance, she wrote code that happens when the button is clicked. She probably did that using an Event Handler on the button. What she didn't have to do however, was write the code that makes the button interact, and change with the press. She didn't have to write the code that makes that familiar clicking noise. It was already there for her. Buttons are in fact an interface. They provide the developer the means of controlling its interactions while abstracting away how that actually works, implementation-wise. This button is part of the API, or Application Programming Interface, that's available from

the application framework that was used to create the app. Because most apps need buttons, this interface has been created to help our developer, or application programmer to use. Now by implementing the button interface, our developer was able to make her code run when the button was clicked. It's worth noting that the code probably also uses a media player API that's provided by the operating system of the device like Android, or iOS. This media player API abstracts away needing to understand the details of how to send audio data to the hardware. The developer knows that he

just want to call the play method of the media player API, and I suppose too, the song isn't stored on the device. It's being streamed over the network, so a web based API call has been made over the internet to get the data. It's actually APIs all the way down to the ones, and zeros providing abstractions at many levels. Let's take a look at what all these interfaces have in common. They all define ways for us to interact, or communicate with an object, whether that object be physical, or software, and as a user of the

interface, we don't need to understand the implementation. We don't need to know how it works. We just need to know what we've been allowed to change, or see. Interfaces abstract away the implementation. Now, while the UI, or User Interface is made for the user of the application, the API is made for the application programmer to use, and extend in their applications with the I covered in our API, let's take a deeper look at the rest of the API acronym. An API is a contract of sorts, it defines how it's expected to be used, and it

defines what you can expect to receive by using it. Think of it as a set of tools designed for software developers like yourself. An API is created to help make your life easier by giving you access to data, and by providing you with an abstraction of the implementation. You know, not needing to know how it's doing whatever it's doing. They save you from needing to create everything yourself. When designed well, they make doing nearly impossible things happen, in just a few lines of code. You're probably starting to see why it's important to get familiar with

them, right? I want to do a quick word of warning here about some naming issues that you'll probably run into. These days, The term API is almost always used as a way to explain web-based APIs. In fact, it's probably safe to assume that when you hear API in the wild, it's most likely that people are talking about a web based API. Now we'll explore those here in a few. However, if we focus on all types of APIs instead of just the web based subset, we'll get a better look into why web-based is are so popular,

so hang tight, we're getting there. APIs are everywhere in your software journey, just about everywhere you look. Your programming language, whichever one it might be provides many APIs. Let's take a look at one that's common in all of them. They all provide some way of working with strings, you know, like a series of characters. You want to make your textile upper case? Just call the API method, and voila, you could probably create that uppercase string all by yourself by doing some sort of low level bit math on each character, but you don't need to, because

your programming language has abstracted that away for you, and provided a handy string API. It exists because this is a common enough problem that developers run into, because these programming language specifications are just interfaces, different operating systems can supply their own implementations so that the code works properly in their environment. I think an easy way of picturing this is to think about how different operating systems like Windows, or Mac OS maintain their files. They're totally different, yet your programming language provides a single API for working with the file system. You can write one script, and

it works in either Mac, or Windows. It's the implementation that takes care of all the details for you. Pretty cool, right? Definitely something to be thankful for. It makes our life so much easier not having to worry about what operating system is being used. The importance of an API to a language cannot be understated. There's been some fascinating legal cases where it's been questioned if the language API itself, again, not the implementation can be copyrighted. Check out the notes for more on that. Along similar lines, there are different web browsers, you know like Google Chrome,

Microsoft Edge, Safari, Firefox, and Brave. Now you might not have pondered this before, but isn't it amazing that you can write code for the web, and it will work in any of them? Now this works because there's a set of web APIs that web browsers all must implement in order to make that magic happen for you. We're standing on the shoulders of giants folks. We really should thank those giants more often. There are authors, and maintainers of libraries that package up code, and solve common problems so that you don't need to do it yourself. Like

for instance, do you know how to programmatically make a photo black and white? Mean neither, but I can download an important image package into my application, and suddenly I can. I just call a method, and boom, I wish real life skills worked this way. I'd import dancing so it could be more fun at weddings, cha cha cha. Frameworks provide an API that allow you to extend what has been provided to make it your own. Like for example, most web frameworks provide you with the ability to add a new route to your web application. It allows

you to write out dynamic data to a template that you specify, and you do all of this with just a handful of lines of code. You don't need to understand how it's doing things, but you do need to know how to write an implementation to what the framework is expecting. In this case, you're using the API, the contract to write a valid implementation that meets the requirements. All of these APIs that we just talked about, they're local to our code base. They exist within our code. We use them to avoid recreating the wheel. That is

to say they assist us in accomplishing tasks that we need to perform by abstracting away a ton of work for us. The stuff that we developers shouldn't be worrying about. We should be focusing on the business problem at hand, and that means a big part of your job is figuring out how to leverage these APIs to your advantage. Now I think it's an excellent time to take a quick break. I just gave you a lot to think about, and I'd like you to take a minute to breathe. Why don't you jot down some APIs that

you've used today, even if you weren't coding. I know that you've seen some in action. If you're having a hard time thinking of some, I'll give you a hint. You're watching a video right now inside of a web browser. When we return, we'll explore the concept of remote APIs, ones that aren't executing locally in our code base, and why that's such a powerful concept. (calming electronic music) It took me a while to find this remote control. It was in the couch. It's always in the couch. Anywho, this remote has an interface on it, right? There's

the power button, and there's a channel changer, and when I press the volume button, it sends my request to my device, and the volume changes as if I turn the volume up using the interface on the device itself, and we know why that's important. I want to remotely control my device. I don't want to get up from the couch. There are of course more, or less lazy reasons as to why you might want to remotely control objects. This cute little robot, for instance, has a remote API. You can send commands to it, and it responds.

It even sends back sensor information. These traffic signs can change based on an API call. This drone here, it's actually remote controlled by an app on my phone. See? It's not just physical objects that benefit from remote APIs. Oftentimes we don't have space on our local machines for all the data that's available. Like for example, have you ever used one of those apps that helps you figure out what song is planning? You send up a snippet of a song you heard playing at a grocery store using your microphone, and it sends back exactly what the

song is. It's usually Phil Collins. It turns out both grocery stores, and yours truly, loves Phil Collins. You don't have room for all the songs in the world on your phone, and with this remote API, you don't need to have all of them. It does all the searching, and processing, and it's surprisingly quick. How can it possibly do that? I don't know, but I love the interface. It's so fast. There's another benefit of remote APIs, computational power. Because an API removes the limitations of your local machine, you can gain access to seemingly infinite amounts of

power. A good example of that is the AR app of Google Translate. You can use the camera on your phone, and in near real time, it's able to translate directly to your screen, like, instantaneously. It's using a ton of processing power to make this magic happen, and that processing is happening elsewhere. (speaking foreign language) It took quite a bit of experimentation, and some evolution of ideas, but over time we finally turned this remote API dream into a reality. Now, I'm gonna drop some history in the teacher's notes, but I just want you to know that

the struggle to achieve this concept of remote APIs was very real, but most of the problem was that there wasn't a standard that everyone loved. Things were pretty clunky for awhile as the ideas were sussed out, but then it happened. A new architectural style appeared that was clear, and allowed us developers to interact with specific resources over the web, and it quite literally changed everything. This style rapidly emerged as a winner, and just about everyone began offering, and consuming APIs over the internet, and what I'm talking about here is REST, or Representational State Transfer. It

was the approach that we needed, and honestly it's the abstraction that we developers deserved. Like we talked about already, the popularity of REST spreads so rapidly. It nearly completely overtook the term API. It's like how we use the word Xerox to mean photocopy, even though Xerox is just a brand of photocopier. Xerox does other stuff too, I think. That's how pervasive REST is. REST is for sure not the end all be all of remote API's. There are definitely some limitations, which we'll discuss here in a bit. Technology is ever evolving, and of course there are

movements that are still advancing the concept of the best remote APIs, some terms you might've even heard, like GraphQL. More on this in the teacher's notes. For the rest of this course, we're going to be doing a deep dive into APIs that are written using the REST style. When APIs embrace the style and constraints of REST, they're said to be RESTful. Cute, right? If you're feeling like you need a little rest, go ahead, and pause me before we do a deeper dive into what it means to be RESTful. Sorry, that was a bad, and obvious

joke, and as a developer you kind of have to make it, you don't really have an option, and because REST sits on top of web technologies, we should probably do a whirlwind refresher of how the web works. (calming electronic music) It might've been a while since you thought about how the web works. There are a smattering of terms that I'd like to reload into your working memory before we talk more about how REST uses them. So let's use the web. I've got my computer here, and on it I have an internet browser. This browser is

a web client, and I'm going to use it to connect to a server. I'm going to do this by putting a location in the address bar, a universal resource locator, or URL to be exact. You might also hear this referred to by a superset term URI, or Universal Resource Identifier. Now our URL here has a scheme portion, and this one happens to be HTTP. HTTP stands for Hypertext Transfer Protocol. Let's break that down bit. Let's grab that last part, protocol. A protocol is also often likened to a contract. It's a little lower level than an

API, but it's similar in concept. You can think of it as defining the expectations of how to communicate. An example that I find really sticks with me is if you've ever been to a rally, and someone does one of those chants where they go, when I say food, you say bar, food bar, food bar, here, let's do one. When I say H-T-T, you say P! H-T-T, H-T-T. I just realized I might've made you yell pee out loud. I hope you're in a coffee shop, that'd be awkward. Anyways, we, you, and I, we just set up

a real quick protocol. I told you how to respond to my specific request, you would have been breaking our agreed upon protocol if you yelled anything else, but P. So the browser creates an HTTP request for you. Along with the URI, it also specifies a particular HTTP verb. In this case, it's using the GET verb, which is used to clarify that this request will only receive data. That is, it won't be making any changes. The server receives the request that was transferred from the client. There's that second T. The server then does the work that

it needs to do, and finally it generates the resulting webpage, and sends back a response to the client, my browser in this case. Now, the most important part of that response is the body. For a webpage that contains the HTML, or Hypertext Markup Language, which gives us the remaining parts, the HT of our acronym. Hypertext is text that can link to other texts. In HTML, we perform that linking with anchor tags. So with that response, the browser renders the page. When one of those links are clicked, they kick off a brand new HTTP GET request,

and the process repeats itself over, and over. In between those clicks though the protocol is done. We made the request, we got the response. HTTP as it was originally designed is a Stateless protocol. Once that request receives a response, it's all done. If you want to keep some sort of state, your client will have to manage that itself, and set it up with each new requests. Check the notes for more on this. There are more HTTP verbs, also known as request methods, besides GET. Most common scenario you see is when you encounter a form that

is used to take information from you, typically you'll see the verb post used to explain that you are submitting, or posting data to the server. Okay, so our protocol that's used to transfer this hypertext is admittedly a little more complex than our rally chant was. There's quite a bit of important information that's included in both the request and the response. You've probably seen query string parameters, and URLs. You know, the stuff after the question mark? This is one way to pass information about the request. Another common way this information is passed around is through specific

key, and value pairs, called headers. Both requests, and responses have headers, and they're used to help further communicate what is wanted as well as what has been sent back. Now, some of the popular request headers allow you to specify information about the content that you'd expect back like the language, or the type of content. You can also state you only want a page if it has changed since a certain time. This technique allows for caching which is a powerful concept. Why get the whole page if you already have it in your local cache? You can

embed authentication information in each request using a header. This way you are essentially keeping your client logged in across requests. The response also contains headers. A super important one is the status code. This lets you know what happened on the server side, and it can convey things like missing documents. I'm sure you've seen the old 404 error. The page has been moved, or hopefully everything is A, 200 OK. It can also explain the content type, how large the data return is, and many more things. Okay, got it? Feeling good about that little whirlwind tour? Remember,

feel free to make me repeat myself if that was way too much. I totally get it. That was a lot of information. It's important to have a basic understanding of these things, because REST sits on top of them. It uses the concepts that were introduced with the web to expose resources that can be accessed, and manipulated. Let's take a look at how the RESTful approach takes advantage of the web, and it's tooling for your benefit, and profit. REST stands for Representational State Transfer. APIs that meet the REST architectural style constraints are considered to be RESTful.

A typical way to teach about RESTful API's is to cover the constraints that define it all up front. I don't know about you, but personally I find approaching learning that way pretty overwhelming, especially from the beginning. I mean we haven't even looked at an API yet, and on top of that, most of the REST APIs that you use will meet all of these constraints. So here's the thing, I promise that we'll go over all the constraints, but let's do it on our own time. Like don't learn them all, right this instant. We can even make

it a fun journey like a RESTful constraint scavenger hunt, complete with prizes. Here are the guiding architectural constraints required for an API to be considered RESTful. We'll check them off when we discuss them, and then we'll loop back once more at the end, and review. Got to collect them all. Sound fun? Good. Let's get started talking about how REST APIs sit on top of web technology, like a little hat. Much like the web, the client makes a request to a server. The client in this case is typically going to be your program, and you'll probably

be using some sort of library to create the request to the server. The protocol used is, you guessed it, HTTP, and it's Stateless. The server won't remember anything about the particular client. If you want to maintain state like your login details, you must send it with each, and every request, and you'll do this using headers, and just like that, we've talked about two of our REST constraints, Client-Server Architecture, and Stateless. You got two knocked off already. You're on a roll now. We should probably talk about what that request was requesting, right? Well, it most certainly

was requesting about a resource. A resource is a little abstract, and that's intentional. It's the R in the URL, or URI, we use the term resource to reference an object, which also happens to be pretty abstract, right? This is because we can use resources to describe just about anything that we build. For instance, let's imagine an ebook store website. On the homepage, maybe there's a list, or a collection of new books. Each of these books is a resource, and we click into that to take a closer look at the book resource, and we see a

link to the author, which is also a resource. We click into the Author Resource, and we see a collection of all the other books that they've written. Maybe we even see a group of fans. Again, another collection, and each of those fans are a resource. Clicking into a fan resource, we can see the collection of their favorite authors, and books. Everything is a resource. Let's change gears. How about an image sharing application on our phone? So we have user resources. Those users post photos, which are resources, and the photos can be loved. So there's like

lover resource. Maybe there's an album that could be created, and there's an album resource that contains photo resources, and albums have a collection of contributor resources. Turns out almost everything we ever want to build can be expressed in terms of resources, and collections. Most of what we want our applications to be able to do to their resources can be expressed through the unfortunate sounding acronym CRUD, and that stands for Creating, Reading, Updating, and Deleting. Now as a user of the ebook site, all we did was a bunch of reading, no pun intended. Actually I did

intend that one. We were reading, right? Just getting the information to display like we retrieved the author page. We made a read request for that page. The web browser used a GET request to that specific author page. Now the RESTful API follows the same logic. Your program sends a GET request to a URI. Then the survey response with data, and of course all the HTTP headers that you've come to know, and love, and the body is typically represented these days as JSON, or JavaScript Object Notation. Now, JSON provides a great way to structure, and nest

your data. Every programming language that I can think of provide some means of turning a JSON string into a native object. Content type is typically something that you can specify on your request if JSON isn't your thing. Now, if you recall, there are other HTTP verbs available. These verbs are used in REST APIs to clearly state the intention of your request. Want to add an author? Post to the /authors, and send the data that you want to update in the body of your request. These fields will be defined for you somewhere. Want to remove an

author? Send a delete to that specific author. Updates typically support the patch verb, and you'll see we're able to represent CRUD, the Create, Read, Update, and Delete using HTTP methods. Pretty cool, right? What this means is that you can interact with any application out there that's exposed their REST API. You could grab data remotely automate tasks, and even smush services together. This is called a mashup, and here's the thing, there are tons of APIs available just about anything you could imagine, and if they're truly RESTful, they'll all feel pretty much the same. You can build

anything. There are services that allow you to do incredible things with a few simple API calls. So now the question becomes, what are you gonna build? Why don't you take a quick break, and when you come back, let's explore a RESTful API together? We'll take a peek at how to use the music streaming service, Spotify, and they're excellent RESTful API. (calming electronic music) You have some new found understanding of how web-based APIs work. I'll walked you quickly through some imaginary REST APIs, and now I'm thinking it's time that we get a little more specific. Why

don't we go exploring together? Now, some of these REST APIs allow you to give it a try from the comfort of your very own web browser, and one of my personal favorites that allows for exploration is the streaming music service Spotify. So here I am at Spotify.com, and a quick word of warning, this for sure is going to look different. By the time you get here, there are teams of people working on the site to make it better, and you're gonna have the benefit of a better website than I have right this instant. So just

a reminder, you should check the notes attached to this video for any breaking changes, and if you don't have a Spotify account yet, don't sweat it. As you can see, it's free, and that same user that you can create, you can end up using for development purposes. So let's assume that I didn't know that Spotify had an API. Now, what I usually do is I look around. So typically most sites store the nerdy stuff down here in the footer. There we go. Developers, that's what we're looking for. It's a community of developers. That's us, let's

do it. Wow, I love a site that treats me well, even as a developer. This is really nice, right? So you can do a ton of stuff since I was last here, let's take a look here from the front. So audio analysis, wow, you can learn about danceability, maybe I will be able to install that skill after all. Oh, cool, audio playback. So you can kind of nice, you can embed a player right in there. You can put a player into your application, an SDK here, that stands for Software Development Kit, and we'll look at

one of those here in a bit, but basically what it does is it gives you an API that wraps around other APIs, and it will feel native to your programming language. Cool, and then let's take a look here at recommendations. Oh, awesome. It will give you specific recommendations. Awesome, this is great. Target danceability, I'm gonna be able to dance, and see this JavaScript here, it's doing a GET to one of their end points. Awesome, this looks good. So let's take a look up at the top here. Let's go ahead, and discover that's what we're trying

to do. We're trying to discover what we're going to do with this API. So let's click into here, and this will give us some ideas of what we can do. Let's see. Real apps that integrate audio features in. This is awesome. I love when sites do this. I find that it's a great way to get inspiration if you don't yet have an idea of how you might use the API. You can see how other people have used it. Cool, so this is the audio analysis that we had seen, a quick dashboard of audio features of

songs, and there's that danceability again. Here's playback, so you can get a player. This is super neat, and these are apps that use them. iPhone app, a listening room, Runkeeper. So you can see here, this is for iOS, and this is for Android based phones. So iOS being like Mac based products, and this is Android based products, and this is widgets. I'm not exactly sure what that is. I'm assuming that's the HTML widgets that we had seen, and that's cool, right? Because it's a web based API, all we need to do is to connect to

it over HTTP. So any of these devices can connect to it. Pretty slick. Alright, let's keep going. So we've got recommendations. That's great. I always need music recommendations. Search, oh, that's nice. That actually feels like a good place to get started, right? And like if we went, and we searched for different things, so there's six degrees of Kanye West, I guess a lot of people are connected to him. Find other artists that are like the artists you like, this is great. Why don't you say, we look at some of the documentation for search? So I'm

going to click this, read the docs. Let's read the docs. Oh, nice, now you might not see this, but there's a brand new web API reference in beta, which means it's not quite ready for everybody, but it's ready for people to try. I'm gonna go look at that. You might actually be there, and be out of the beta period by the time you see this. Okay, so let's take a look, and let's see about this Search API. Let's see, Search API. So let's go ahead. Let's click into there. As you use more, and more APIs,

you'll get super familiar with reference documentation like this. This is explaining the contract of what we need to do to use this API. So you'll see here that there's different parts. So this is what the request is that we're gonna be sending, and it's saying here that this is a header, and this says whether, or not things are required, and this indeed is required. So this is authorization here. There's a header that's required in the request for authorization. The authorization means it knows what you're allowed to do, or authorized to do. Spotify, and many other

APS use the concept access tokens. So then, so that's a header, that's the header that's required, and so here we see this query parameter, right? So query parameters, and you'll see that this one's required this queue. So this is the search query, the keywords, right? So, and here's an example of what that is, and this is showing you that it needs to be URL encoded. There's some more notes on this here in the bit. So no, we have queue is required, and also type is required, and type is like album, artist, playlist, like the type

of resource that is available in Spotify's API, and if we keep scrolling down, there are more, there's more optional query parameters that are available. Really help you specify your search, very rich API they have, and then it shows you this response. So this is what's gonna come back. So you'll see that you'll get a header, and the status code, very important. We'll say 200 okay. If it's good on success rate. On success I'll say 200 okay, and the response body contains an array. So like a list of artists, objects, or album, artist, whatever it was

the type you were looking for, and it's going to be in JSON format, just like we talked about JavaScript Object Notation. And so you'll see when there's an error, there'll be an error code, and the body will have the error message, and then there's some more notes here, and these are really thorough. This is great. So in code spaces, that's what we saw. We saw that %20. It's making sure that you can't use a space, otherwise it breaks the URL. So this is how you do that. You'll see there's lots of different information here. Yeah,

you can use asterix, and show you in all sorts of ways to do fun queries. Let's go ahead, and try this out in the web console. It's pretty slick. So what this does is it lets us search for an item, and it's showing us how it's doing. It's doing a GET, and it's does have some authentication required. So we will need to build something here, but you'll see over here it's showing what it's doing. It's doing a GET to this URL, and this is code here that will actually run, and you'll see as we change

the fields here. So I'm gonna change this to a very popular artist around my house, Lizzo, and you'll see that it updated over here. It updated my query, and the type is set to artist already. So that's fine, and we have this OAuth Token that we need to get. So we need to get this token. So again, this is the, what are they authorized to do? So we're going to go, and choose Get Token, and it's telling us that this specific endpoint doesn't require any specific scopes. So these are scopes that you can do. So

when you build this token, it's saying for using this key, these are the things that the people are able to do, and we don't need to do anything specific for this. So let's just go ahead, and let's not check any of these. We don't need to modify a private playlist, we don't need to do that. So we're going to do Request Token, and here's it's gonna ask us to log into Spotify, and if you have Spotify, go ahead, and log in, and if you don't remember, it's free, you can totally just come in here, and

do a sign up. And we can put in our emails here. So I'm going to put in mine, and here's a little trick, if you don't know this yet, I'm gonna put in API course. Let's do API course like this@gmail.com. My email address is CraigsDennis@gmail.com, but if you put a little plus here, you can kind of categorize things your own. So just a little trick, and that way if you're worried about emails coming in, you'll know that they're coming in from that address. I'm gonna do the password to my luggage, which is one, two, three,

four, five, just kidding. What should we call you? I love it when you call me big papa. Alright, so my date of birth is November 19th, and I was born in the wonderful year of 2000, just kidding. This is awesome. I love this Spotify. Thank you for being inclusive, inclusivity matters. I'm gonna choose Male. I don't want to share my registration data, and I am not a robot. I promise. I think I'm not a robot. Identify the crosswalks. What is that? Alright, so there's one that's definitely a cross walk. That's a crosswalk. I mean, I

could walk across the street here, I could. Alright, I passed. I'm not a robot. I'm gonna click Sign Up. Here we go. I'm gonna save that password. What if I turn on sync? All logged in as Big Papa. Here we go. So I'm going to click Agree. I'm going to pop back to the page, and you'll see now this is filled out. Now one thing I do want to point out here is that my token here, my key is on the screen, and if a hacker were to pause my screen, and copy that down, they

could essentially do things to my account on my behalf, but I of course know that, and I'm gonna delete this token later. Remember this is like leaving your car keys on your driver's seat. You probably don't do that. So treat these keys the same, and keep them safe, and with you. So I could just copy this whole command, and paste that into my terminal, and it would work. We'll do that in a bit, but what I want to show you first is that you can do this, Try It button here, and what happens is what

comes back is this beautiful JSON. So you'll see that what's being returned here is as artists, and it's an object that has the search that we built, and then here is this items, and you'll see that it's an array, because there could be multiple artists named Lizzo, and I guess looks like maybe there is. Yeah, it looks like there's actually another artist named Lizzo, popularity 88, and what's this Lizzo's popularity? Her genre is Escape Room? Man, I feel old. One thing we can do is we can look, and see if there's these external images so

you can kind of take a look, and see if it's them. I'm going to click Go To Here, and we'll see what happens, and there she is. Lizzo is on all the time at our house. Once my daughter has figured out that Alexa could play music, they're like play Lizzo, Alexa, play Lizzo. Alexa, by the way is a Voice User Interface, right? There's the I again. So I'm gonna get back to our tab. And we will go now, and we see here that she has an ID, because we're in this artist, right? So we see

here that she has this ID. I'm gonna go ahead, I'm going to copy this, and you also see that there's another API call here that we can do. There's this HREF that will get her specifically, right? So there's the /artist, and there's /herID. So if we call that it would get information about her. Again, I'm gonna make sure that I copied her ID here. I'm gonna scroll down a little bit more. Think there's the other Lizzo. Let's look. I think there was a thing where we can look at the page. Yeah, here we go. So

here's external URLs, and you'll see this as an API. This is the actual Spotify page itself stuff. So if I'm gonna do this, and I'm gonna right click. I'm gonna say, go to. This is Lizzo's actual page, and this is how it's displayed, right? As a web page on Spotify. If you scroll down here, we'll see that there's this popular, there's her popular songs, Good As Hell, great stuff. If you don't know her, use this link, learn her. I happened to know that we can get a list similar to these popular songs using the API.

So let's go back to our reference. Okay, so we're back here in our reference. Let's look at the artist API. So we're gonna click on Artists, and again, I'm going to go into the beta, whether they be a reference might be what's live for you, and I'm gonna click into the Artists API over here. I'm gonna scroll down a little bit. So there's get an artist, get an artist's albums, and what else do we have? Get an artist's top tracks. This is exactly what I wanted to do. Okay, so again, here's the docs about that.

I'm gonna try this out in the web console. Okay, so get an artist's top tracks. It's gonna do a GET, and this is the end point. So we're gonna just kind of, it needs that ID, right? So we're gonna put that ID in there. It's coming defaulted with somebody. So I'm gonna go ahead, and paste Lizzo's in there. Okay, and the country is US, and you'll see that again, it's changing. So see how the her IDs here, country's US, and we're gonna pass our private keys along. I'm gonna click Try It. Alright, so now we've

got a list of tracks, and each one of these tracks has what album it showed up on. Okay, so again, this'll be in the same list, their top tracks as we saw on that page, which is super neat, right? There's the, because I love you song, and let's keep going a little bit. You'll see how the URI's here, they use a different style URI with the colons to separate, but it's Spotify artist, and then the ID. And we'll see here that there's this preview URL, which you could actually just go ahead, and open, and it

will start playing this song. Pretty cool, right? You can get access to all of Spotify's music library, and you can build tools that extend their platform. I highly recommend that you go, and take a look at what people have built using these APIs. Super impressive. Did you notice how fast those results came back? How could it do that search so quick? Oh, wait a second, does it even need to? The results don't change all the time. It's not like Lizzo is dropping a new song every minute. Though, I wish she would. Those results are definitely

cacheable. Ding, ding, ding, Casheability is also available on the client, and we'll get to that here in a bit, but this is a great example of a Layered System. I'm almost positive that Spotify has set up things so that returns that same JSON from its own server side caching mechanism. It's not on every request. Now as a user of the API, I don't know how it's doing that, and frankly I don't care. I want it to be available and fast when I hit that specific URL, and as Lizzo might ask, baby, how you feeling? I'm

feeling good as hell. That was fast. Spotify is just one REST API. There are tons, and tons of services out there. There are even services that exist only as APIs. Let's go ahead, and take a quick break. I'd love for you to take some time, and think about what you might be able to build with the Spotify API. For instance, while I was using the API, I had this idea pop up. I'm often at festivals, and I'm having a hard time figuring out which band I should go see. There's so many. I love to have

an app suggest me which of the bands that are playing that I would most likely enjoy based on my listening cabinets. I'm pretty sure you could do that just by using the Spotify API, and a list of the bands performing. If you end up building this app, please share it with me. What other interests do you have that provide an API that you can use? Check the notes for more ideas after you come back from your break, let's dive a little deeper, and make use of an API using our own tools. See you soon. No,

really take a quick break. Seriously, it'll do you good. No benching. (calming electronic music) While I realized that exploring an API on a website is informative. It might not feel like you're actually using that API. I think the next logical step in exploring is actually making that request yourself from your computer, not from a website. Let's use a different API, this time let's use Twilio. Twilio is a company that loves APIs. In fact, that's most of what the company is. It's a company for developers that helps abstract away telephone communications, well actually all kinds of

communication channels. It lets you bring communications into your applications. It allows you to make, and receive calls, and text messages, and a whole slew of other things. I need to be a little upfront with you here. I love Twilio. I mean, I love it so much I even applied for a job with them, and I got it, but even if I didn't, I would still show you how cool their APIs are. I mean with a single command you can send a text message. I remember when I first did that, I was like, wow. That level

of abstraction is amazing. How does that work with all the different cell carriers, the varying standards, and networks? I have no idea, and I don't need to, that's the beauty of this API. Let's get started. So I'm here at Twilio.com, and again a word of warning, this will most likely look different as Twilio is constantly making improvements. So please check the notes for any changes to this flow. So first things first, let's sign up. We'll be able to use a free trial account for the rest of this course. Let's sign up with my information. I

am Greg Dennis, and again I'm gonna use that trick. So I'm gonna say CraigsDennis+ let's say API course, in case I've already done that one @gmail.com, and I will set my password too, and I am going to accept the terms, and services, because I've read that. And I'm gonna start my free trial. Save my password. There we go, and it's sent an email to my Gmail. I will go check that real quick. There we go. I've got a email, and I am going to click on that link. Let's do this. And we'll paste it here.

Verify my account, and I am logged in. Alright, so I'm gonna put in my phone number, which is (503) 461-5537, and this phone number you provide will be used for authentication for the Twilio Console. Somebody might contact me of free onboarding. That sounds great. I'll check that. I'll click Verify. So 708655. So in trial mode we can only communicate with numbers that we verified. So do you write code? I do. I write code, I write Python code. My goal today I'm gonna use it in a student, or hackathon project for sure. I'm gonna send, or

receive SMS. SMS is a Short Message Service, which is text messages. We're gonna send text message. So the way Twilio works is you buy an actual phone number. Well, let's do it. So we'll get this trial number here. This number got automatically selected. It's fine by me. (201) 584-8089, and I'm gonna choose it. Let's say Choose This Number, and just like that the number is mine, and I can program it, and we'll do more with that later. So I'm gonna click Done. So there's some notes here, right? You can only send messages, and make calls

to verify numbers. That's how our Twilio trial account works right? Notice also, we have $15, which is more than enough money to do anything we're gonna do in here, and it's also says that messages, and calls include a note about this coming from Twilio trial account. Okay, that's fine. What do you say we send a text message? Let's do it. So the way that things work is over here, there's a little menu, and we have different things. As you can see, there's a bunch of stuff available. We're gonna choose this very first one here, this

programmable SMS short message service. I am also going to pin that to the dock so that I can get to it easier. So it'll always be there, okay? So, you'll see here, it's pinned. Well on this page, I'm gonna choose, Get Started. Let's do it. Now, this step allows us to explore the API like we saw on the Spotify site. You'll see as I change things here so let's change this body to say, ahoy, you'll see that it changes the code that's over here. Fun note here, ahoy was the first word ever spoken over the

phone. So ahoy is kinda like hello world of phones. So I'm gonna go ahead, and click Make Request, and I got the text. Of course it's prefixed with sent from your Twilio number, but whoa, right, I just sent a text by pressing a button. Let's take this a step further. I'm gonna copy this code, and actually first before I do that, I'm gonna check this show your Auth Token. Just like Spotify, Twilio uses Auth Tokens, and their private keys, but I trust you, and also I'm gonna delete this later. I see you hackers. So now

if I come over here, and I click this Copy icon here, it will be in my clipboard. Now I'm running on a Mac, so I'm gonna open up my terminal and I'm going to paste. So see how this is the URL that we are going to post to, right? We're going to post, because we're gonna be creating a new message. Notice here, this is my account SID, or String Identifier, and because we have a JSON here, this .JSON, that tells the Twilio API to return JSON, and we use form a URL, and coding here. This

is what this data URL, and coding is, and this is the two. We're gonna send it to my phone number, and it's gonna be from our Twilio number, and the body's gonna be, ahoy. So I can come in here, and I can change this code, right? So I can, and instead of ahoy, I'm gonna make it say, ahoy from terminal, and this dash U here is setting up the authentication of the account SID, and this is my Auth Token. So when I go ahead, and press Enter, we'll get some information back, and it tells me

that it was successful. It will give an error if it didn't, I got my text message. So this command is sending a post, which is great, but I can also use GET to receive the messages that have been sent. So kind of like a sent log. So what I'm gonna do is I'm gonna use the up arrow, and get the information back. I'm gonna change to GET, and then I'm gonna get rid of the rest of these lines, which I'm gonna do with GET in here, and do Control+K on the Mac. Look in the notes

for how to do this in Windows. So we're gonna say all of the messages that were sent to this, and if I go press Enter, that didn't work, because I left the trail at the end, have to press up again. So I'm gonna get rid of this trailing slash, because that means like continue on to the next line. So here we go. Now, I need to have my account SID. So let's do that again. Let's go press up a couple of times. So I forgot that I need, we're gonna need to keep our information there.

So let's just go ahead. I'm gonna get rid of all of these lines. So again, that's Control+K, Control+K, and this is dash U, and we're doing a GET to this account, and we're saying all of the messages that were ever sent from this account, let's take a look at that, and we're doing a GET, so we're not doing a post. So we're gonna show a list. There we go. So again, you could format this, or make it prettier, but for now though, let's keep exploring some more tools. Awesome job getting that running on your local

machine. It feels pretty good, doesn't it? What a cool skill you now have. You can send a text message from your machine with just a single command. Now, believe me, this is just the tip of the iceberg of what you can do. There are so many more Twilio APIs available, but for now let's take things a step deeper. I don't know about you, but I'm a little clumsy when it comes to long commands on the terminal like we just did with Curl. When exploring API's, I really like to lean on a tool called Postman, and

I think you'll enjoy it too. Why don't you take a quick break, and then we'll check out Postman? (calming electronic music) Postman is a wonderful feature rich tool that I use all the time to explore new APIs. It started out as a Chrome Extension, but recently became a full fledged application. It's super handy. I love how it can help you organize your learning, and I think it's an excellent exploratory tool too. Let's dive in. Postman can be downloaded at GetPostman.com. Go ahead and pause me while you get an installed. This right here. Download the app,

and I'll wait, and when you're done un-pause me, All set? Okay, so here it is. I've got an installed too, and when it comes up it will have this Create New, and typically when I end up using this tool, I'm working with a specific API, and what I'd like to do is to create a collection to keep all of the requests that I make grouped together. So I'm gonna choose Collection here. So Create New Collection. Let's recreate those calls that we made to the Twilio API using Curl. So let's do that right here. So we'll

call this the collection name is gonna be Twilio, and then I'm just gonna click Create. Down here there's a little window thing, a little bar over here. You can see that you've got your collections over here. So we have a new one here called Twilio and in here you'll see that we can add requests. So I'm going to go ahead, and click Add Requests. So let's build that message log. Remember that was the GET that we did over in the terminal. So I'll name this request, that request name is message log, and I like to

make a description here about what's going on here. So this is gonna be all messages sent from my account. That's what we were looking at, right? That's what that message log was, and if I'm taking notes, usually what I do is I drop a link to the documentation about what the resources that I'm looking at. That way I have a quick way to get back to it to look at it. So one way to do that is just go find the documentation. So if we just do Twilio message resource doc, that's what I had there

before. So that's gonna find the resource for the messages, and a resource reference. That's great. And the way that the code here works here is very similar to like we saw on Spotify, the different things that are available. There's the create message resource, and each one of these kind of has its own little heading, and there's some code over here that we can switch. So I want to look for list all messages. That's what we want with the message list, right? So I've got this example, and I'm gonna grab the URL, and I'm gonna come

back over to Postman, and just drop it in there, and a Postman uses, here, this is marked down. So I'm gonna use brackets, and say Twilio documentation, and then if I put parens, I can paste the link there, and that will make a link inside of my notes. Let's scroll down a little bit here. Twilio offers a ton of different API, so I could break this down even further with this thing called a folder. So let's open this up actually, and let's make a new folder here, because you know, there's so many different APIs, we

might be playing with a bunch of different things. So what I like to do is put these in folders. So let's make a folder. We'll make the folder called SMS. Okay, and we're gonna add that to the SMS folder. Okay, so what does the saying is we're gonna make this new request. We're gonna create a new folder called a SMS, and when we click Save, we'll see that here underneath Twilio we have this SMS now, and there's our message log as it were. And so what's happened here is it's created a tab for our new

requests that we've made, and you'll notice that there's a little twisty here, and there's a tab, and there's the link to my documentation, which is handy as you'll see as we're going through this. So let's go grab that URL that we had. I'm gonna go back to my terminal, and I'm gonna press the up arrow, and I have that there. If you don't have this go ahead, and look in the notes, and I've got a copy for you. So I'm gonna copy that. I'm gonna come here, I'm gonna put the request in here. One thing

to notice over here is there's this dropdown that says GET, and we can send different types of, here's the different verbs, right, that we can send across HTTP verbs, a bunch of them, and we're gonna leave it at GET right now, because that's what we're gonna do. We're gonna get the messages, and I think we're all set. So let's go ahead, and click Send, and oh we got an error. You'll see that we got back a 401 Unauthorized. So if I mouse over it, I see more information, which is nice, and if I scroll down

here a little bit, here's the error message that came back from Twilio. It says your account SID, or Auth Token was incorrect, and oh yeah, we didn't even pass them. So you can add that authorization to your request by this little tab here. So next up param, this is authorizations, and here we'll say type inherit Auth from parent. Oh, that's actually a great idea. We're gonna be using the same account SID, and Auth Token anyways, so we should just use it from the parent, right? So I'm gonna open up my Twilio collection, which is here.

So if the screen ever gets closed, this little guy here pops out. So I'm gonna go to my Twilio collection, and right click on the buttons here, and I'm gonna choose Edit. Here we go, and we'll come over here to authorization. So what this does is all requests, will share this if they have, you know, inherit from parents. So we'll get this authorization. It's used for every request in the collection, which is what we want, and we're gonna change the type to be a basic Auth, which is what we're using there. So we'll click Basic

Auth, and look at this. We were gonna put our super secret information here, but it's saying heads up. These parameters hold sensitive data to keep this data secure while working in a collaborative environment. We recommend using variables. I don't know about you, but whenever I see a security warnings, I like to follow that. So let's follow that. So let's, there's variables here. So it says, learn more about variables. If there's also this Variables tab up here, right? So let's click into Variables. Okay, so what these do is we create a new name, and it will

have a value, and people can set on their own machine there, these own values. So this is a good way of not accidentally sharing out your keys. So the things that we want is we want to have the account SID, which is a string identifier. So Twilio account SID, and the way these these work is, there's this initial value. This is what people will see when they come in. So we want them to fill out their own. So we'll say your account SID. So if anybody is using this, you're gonna share it. That's what they'd

see, and we'll get the current value. So that's over in my Twilio console. So if I go to Twilio/console, which is the main page, once you log in, you'll see here that I have my account SID, here it is, and then there's a little copy button. So I'm gonna copy my account SID, and we will paste that, and the current value is my account SID, and then we'll do another one. We need the Auth Token. We'll say Twilio Auth Token it will say your Auth Token, and again, what we want is this Auth Token. I'm

gonna copy that. And paste that here. Awesome, and I'm gonna click Update. So I'm gonna go again again, and choose Edit, and I'm gonna go to Authorization, and now that we have it, Postman allows you to use those variables wherever you want to, and you can replace them by using a curly brace. Sometimes those are called mustaches. If you look at that sideways. So we'll do Twilio account SID, right, so it's double mustaches, right? So mustache, mustache, and then it does that. So mustache, oops, and for the password, we'll do Show Password just so we

can see that we're doing it right. We'll do mustache, mustache Twilio, Auth Token, that's how this works. So there we go. So that is going to set the authorization for all of the collections to these variables that are local to our machine. Make sense? There we go. So we'll click Okay. Update, and now let's go ahead. I'm gonna close this window here, this little nothing, and I'm gonna click Send. Okay, so we've got the authorization headers in place. We'll click send. There we go, beautiful. Much nicer formatted. See here we got our messages, we've got

an array of messages that came back, and we have ahoy from terminal, and we should have another one. Now, there's nice URIs that we could go look at other things like feedback that came or the media that's attached to it, and here you'll see the original that we did that was ahoy, and you'll see that the cost of it was 0.07 of a cent. So awesome. Now that we've got all of our foundations set up, we've got our collection, and we've got our variable setup, let's go ahead, and let's make it so that we can

send a post from this right after a quick break. (calming electronic music) So we've got our message logs all set up in Postman. So now let's use it to create a post request. Now since we want to use that same authorization that we use in the message log, we should put it in the collection, and folder. So let's go back over here. Again, if this is closed, you click this little like I hit to pop this out. So we're gonna add a new request inside of the Twilio SMS here, and we're gonna make Add Request,

and the request name is going to be Create a Message. So we'll say creates a text message, and then I'll see if I have the Twilio docs up still. I don't, so we'll have again, we'll search Twilio message. There it is filling it out for me. Message, resource reference. And over here on the left nav we can see that there's different bits. We want this create a message resource. This is definitely what we want. You see there's the URL. So we will copy that, and bring that back over to our Postman. It will say Twilio

Documentation. Awesome. And it's in the SMS folder, because that's where I started it from. Let's bring this all the way up, and we'll say save to SMS. That's the folder. Awesome, so we have this Create a Message. So let's see in order to create a message, remember we're gonna do a post, and it's that same URL that we were using from the get message log. So see how there's two tabs here? So I'm gonna switch back over to my GET. Oh, look at this. We see here that the account SID is in there, and we

don't necessarily want to put our accounts SID there for each one. We want anybody who uses this to be able to use it. So let's change that to use a Twilio account SID. So that way we'll use the variable that we've created right? So that's gonna replace that automatically here, and then you can see what it is by mousing over it, and now let's click Send, and make sure that we got it. Cool, now this is a usable URL for anybody if we were ever to share this. I'll show you how to do that here

in a second. So we'll paste this here, and when we're creating a message, we're gonna need to send some additional information, right? So if we click over here, and we click on this body tab, so we're gonna send some values, and in the Curl command we sent that using a form URL encoded. So let's do that. What were those values though? Oh, you know, I should pop over to the documentation. I am sure glad that I made that link so I can click here. Open that up. Cool, so we definitely need a two. That's right,

we need a two from, so you may also need to pass a body, or a media URL with a messages content. Media URL, does that mean I can send pictures? Cool, we should do that, shouldn't we? Cool, so there is two, and there's from, body, and media URL. Okay, cool. Now I'm gonna set this to the Curl and because you see these different programming languages here, we're gonna set this to Curl. So it's in the right format here. So there's media URL, and the two in the front half capital F's there. So that's the format

that we want. So we'll say two, and that's my number that we want to send this to. So this 1-503-461-5537. So let's add a body. So we'll do body again, need to make sure that it's checked. So body, and we'll say sent from Postman, and you can actually send, in these messages, you can send emojis, which who wants a text manager without emojis? My frequent used one is the mussel taco. Frowny love rocket, sent from Postman, awesome, and why don't we send a media URL? We saw that there in the notes. So we'll say media

URL, and the URL, we can send any sort of a GIF, or Jif, or a whatever, however, whatever you can send here whenever you want. I'm gonna copy, and paste one of my faves that we can send. Feel free to use your own image. I've left some fun suggestions on the notes, if you want to copy. Giphy is a great site to find those. So let's see, we get to body media. Now, we need from, we need from, so that's our Twilio number. So I'm gonna click in here, and I'm gonna say from actually, this

is something where, this is my personal number, so why don't we add a variable for that? So I'm gonna flip back over here to the Twilio variables. So we'll come back to edit, come in here to variables, and we'll add a new one for let's call it Twilio number, and I'll say your Twilio number, and our Twilio number. Let's look at that, and it's in the console. So Twilio/console, here's our trial number, that's what we want. Copy, and paste that, and we'll paste that here. Here we go, say Update, and so the from value we

can use Twilio number. Awesome. Alright, this is feeling good to me. Here it goes, nothing. We're gonna click Send, and boom, 201 created awesome, and I just got my text message, and there's my GIF. Pretty cool, right? So creating an MMS, or multi messaging service message is a lot more difficult than this if you were to attempt to do that by scratch, but the abstractions in place, right? So it was pretty much seamless for us. Now you'll notice here that the message says maybe you won't notice the status here says queued, but if we go,

and we look at our message log, and we run this thing again, we can see that they're sent for Postman, there's our emoji. And here's some more information, and if we scroll down a little bit more, we'll see these sub resource URIs and now we can see this media that was sent along. So let's go ahead, and I'm gonna just click this link, and watch what it does. It's gonna make a new GET requests. Now there's a bit of a problem, because this GET request is outside of our collection. So typically when I need to

do something like this, there's a little hack that you can do so I can get the authentication information. So let's just click Save, and I just call it, you can just call it that if you want to, and then I'm just gonna call it temp, because we'll delete it when we're done here. So we'll just call it Temp. Say that to SMS, and when we run this, we'll see that we got back the list of medias, and because you can send multiple, right? You can send multiple pictures in a, and we'll see here that there

is an official one, and see how it is accounts, and then messages, and then media there. There's sub resources. So I'm gonna go ahead, and I'm gonna click on that. And if we wanted to, we could run this request, and it would be, it would show information about the media, but if you actually remove this .JSON, it will show the form of whatever the media was. So we'll make this request, and watch what happens. Let's see, we got back my GIF that I sent. And with a request of this size, we probably don't want to

be making that request again if we don't need to. So this sounds like the job for client side caching. Well let's see if our API supports caching tricks. So what I'm gonna do is I'm gonna expect the headers that are on this response. Nice, so it has this last modified header here, which is a good sign that it does support caching. So let's go ahead, let's copy this value. So I'm gonna copy this date here into the clipboard, and if I go up to where my request was made, if I come into headers here, I

can add a new header, and I'm gonna say if, and you'll see that Postman is doing a really good job of showing you what's available. So if it's been modified since that time, because this is basically what your client would do, right? It says, if this thing has been modified since this time, then show me anyone, otherwise don't. So that's what this does. So I go in, and go ahead, and I'm gonna go ahead, and click Send, and you'll see that my API returned this time not modified. So our API supports caching, which ding, ding,

ding, means we covered another part of RESTful API constraints using standard HTTP caching mechanisms like last modified, and etags, a RESTful API should support caching. It's up to you to maintain the cache on your client, and decorate your request, but this can come in really handy to avoid making unneeded requests. Awesome, so let's make sure that we've got these saved. Do you see these little orange dots here? Means that they haven't been saved. So I'm gonna click on it, and click Command+S, or Control+S, and I don't really care about the temp, and I don't really

care about this one. That was just kind of exploring. So let's take a look here. We have this temp, we can choose, and say Delete, and we'll delete it from temp, and now he has this, have our message, and our create message. One more quick thing before we wrap up. I wanted to show you, you can actually generate code from this. So if you click in here, you can see, here's an example of generating a code snippet. It's gonna actually run through the code, and set up everything that you need to run this code. Now

there are things called helper libraries that will do this, and Twilio has one, and we'll look at that here in a second, but this is pretty slick, right? Really, really powerful, and you just copy it to the clipboard, and boom. Pretty powerful, huh? Awesome job diving into Postman. It's a super powerful tool, and it keeps getting better every day. There are so many features that we didn't even cover. We barely scratched the surface. Check the notes for where to learn more. We saw how to organize our requests together into collections as well as share common,

and secure values by using variables. We learned how to add different values to your requests, both in form, values, and headers, and we also saw how to navigate through various sub resources by clicking URIs. We even saw how to create actual runnable code from your request. While we were in the Twilio documentation, you might have noticed the code examples on the screen. On that page, it's possible to tab between various language implementations, and solutions. Many products offer what is known as an SDK, or software development kit, or Helper Library that allows you to interact with

their product in your native language. As you can see, it abstracts away the REST API completely. Let's take a look at the Twilio Helper Library next. Before that though, just a quick reminder to make sure that you check out the notes on this video. There's a link to a repository of built out collections that are ready for you to use. There are lots of great API's to practice with. Postman and Curl are both great tools for accessing, and exploring APIs. However, when it comes time, most likely you're gonna need to write some code. As we

saw in Postman, you can actually generate code. All programming languages come with some sort of way of making requests, and as you know, HTTP requests are all we really need to interact with REST APIs. Now writing that sort of code is totally fine, but you'll find out that you end up writing a lot of what is known as boilerplate code. Now, by boilerplate, I mean code that is repetitive, and almost always the same just with a few tweaks. Many products, and services have created a solution to help you avoid this problem. They're often called helper

libraries, or SDKs, Software Development Kits. They'll be specific to your programming language. These libraries help to make your code more concise, and legible. They usually also provide additional documentation for your editor, which I find super handy. Let's go check out some of these helper libraries. Let's explore both JavaScript, and Python Helper Library. In order to do that, I'd like to make sure that you have both Node, and Python installed under computer. I've put installation instructions in the notes. Let's get started with Node. So I'm gonna open up the terminal on my Mac, and I'm gonna

make a directory called scratch, and I'm gonna change into that directory, and in here I want to make a directory called JavaScript, and I'm gonna CDN to that directory, and I'm gonna open my editor in this directory here. So let's say code. I'm using Visual Studio Code. So we're gonna open up Visual Studio Code, and over here in our directory, I'm gonna add a new file, and I'm gonna just call it explore.js. Alright, now what I'm gonna do is I'm gonna install the library in Node land that is called NPM. So I'll open up a

little terminal here in Visual Studio Code, and I'm gonna run NPM, install Twilio. And that's gonna go out, and it's gonna get the library so that I can use it, and I can use it like so now, now I can say const Twilio Goals require Twilio. And then we're gonna initialize it. So we'll say const client equals new Twilio, and as you can see, it takes an account SID, and an Auth Token, and I have those available for us here. So here's my account SID, I'm gonna copy that, and we will make the Auth Token

after that. Alright, so we'll put that, awesome. Now can you think of anything wrong with doing that with putting my account SID and Auth Token there? Well, right now this is just sitting on my machine, but if I were to upload, or share this with anyone, my credentials are sitting right there waiting for anyone to steal. Typical solution here is to use environment variables, and we'll do that when we build our application, but this is just a friendly reminder. Be careful with the keys. What we're gonna go over here might very well be overwhelming, but

it will make sense someday if you stick with it. I promise, oh, I've added notes, but really don't let this stress you out. The reason why I'm talking about this behavior is, because the Twilio JavaScript client works like most JavaScript libraries. It's asynchronous, and it relies on a concept called promises. So the way the promises work is that you set up handlers for when your method call actually completes. So to get our message log, we use this method. There's a method called, so we do client.messages.list, and what that method returns is an object that is

called a promise. It's a promise of a future value. The future value in this case will be our messages. So promises have an important method on them, and it's called then. So I'm gonna go ahead, and chain on that message. I'll say .then, and this method should be given a function that accepts of value. So I'm gonna pass it a function. Now in modern JavaScript you can use what are known as fat arrow functions. So what I'll do is I'll put the name of the value, and the value here is messages, right? Because this is

what I'm expecting to be returned, and then I'm gonna put a fat arrow, which is an equal sign of greater than, and then I'm gonna put the function body. So let's just log out the most recent message. Okay, so we'll do a console.log, and I'm gonna use back ticks so that we can get a string interpolation, and I want it to be the first one in the array. So we're gonna say the most recent message is dollar sign, curly brace messages, zero, because it's in array.body, and that is a long line in, this happens quite

a bit. So typically what we do is when we do this chain, is we press Enter here, and we put that on its own line, still pretty long still off the screen, and if I ask this to format with prayer, let's see what it does. There we go. Let's see, you know, it's done a pretty good job of getting things close. So, and then again, just to show you that this is running asynchronously, I'm gonna below making this call, right? So this is, looks like it's after that calls made. Well it is after that call

is made is just, that call's gonna be asynchronous. I'm gonna say gathering your message log. So let's go over it real quick. What's going on here is that we are getting a hold of the client, and we're setting up a new client so that all requests made against this client are authenticated, right? So that's our account SID, and our Auth Token. And then we're gonna use the client, we're gonna use the messages out there, we're gonna do a list, and that list is an asynchronous method. Now while this has been abstracting away, we know what

this is doing. It's making that same GET request that we did in Postman, and in Curl, and we know that it will return a JSON response, but because this is asynchronous, immediately it's going to move on to the next line. It's gonna say gathering your message log, and when that call to list returns, it's gonna run this function, and it's gonna pass in the return value of that response to here. Now you should note the return value here is an actual object. It's not a JSON response. That sneaky little Helper Library of ours has also

abstracted that away for us. It took that HTTP response, which has a body of JSON in it automatically turned it into an object for us, and you can see that here, it's an array of objects, right? So that's at the zeroth, okay, so let's run it. So I'll do clear down here, and we're gonna say Node explore.js. So we should see gathering, or message log, and then the most recent message, fingers crossed. Here we go. Awesome. Yes. Okay. Now, one thing that we should make sure to do here is to capture any errors that might

have happened asynchronously, right now if an error happens, it'll be swallowed. Well actually, let me demonstrate what that means. This bites me all the time, and I don't want it to bite you. Let's say that you accidentally trimmed the last character off here, the seven of mine. Let's take the last one off here. So I'm just gonna do that. So it's an invalid SID, and I'm gonna save, and I'm gonna run it, and it's gonna say gathering your message log, and then it's just gonna end out no error, no nothing, but the results never came

back. So what we need to do is we need to catch any errors that might occur. Every promise has a method named catch, and what might not be clear here is that this then here, that's returning. This is actually also a promise. So I can just chain on here. So I can say .catch, and I'm gonna catch an error, and again, fat arrow function, and we'll just log that error. So I'll say console.error.E-R-R. Okay, so now we've got, it's gonna chain, and if anything happens, it's gonna send the error. So let's try that again. Let's

see what happens now with our catch in place. Awesome. It tells us that it wasn't found, because that's wrong, right? Great. This is probably a good time to remind you if that was way too much information that you can, and you probably should scrub the video back, and watch me do it again. I guarantee that you'll catch some stuff you missed the first time, and at the very least, you'll spot a dad joke that I made at the very beginning of this video. I had said, this will make sense eventually. I promise. I'm sorry. I'm

kind of obligated to make that joke, and if that doesn't make sense yet, that's also okay. Check the teacher's notes for more information on promises. Let's change gears, and take a look at the Python version of the Helper Library right after a quick break. I know I need one. See you soon. (calming electronic music) We just took a look at the Twilio JavaScript Helper Library, and now let's take the Python Helper Library for a spin. Now, if you don't have Python installed, pause me, and check the teacher's notes for instructions. In my terminal, from my

scratch directory, I'm gonna create a new Python directory. So mkdir Python, change into that, and while we're here, let's just check, and make sure that we have the right version of Python. So I'm running Python 3.7.3. As long as this first three here is a three, and not a two, we're good to go. Python uses the concept of virtual environments. These allow you to install packages local to this application. So let's do that just to be safe. So, that's done with the dash -m, and then venv, for Virtual Environment, and I usually just call that

.venv. So that will create a directory called .venv that is right there, and here we go, and what happens is now I'm on a Mac, so this might look a little bit different on Windows. If you do .venv, there is a directory called bin activate, and I'm gonna source that file. I think that's a .bat file on Windows. Check the notes, and you'll see now that I am activated. So I've got this .venv here. I'm gonna go ahead, and open up my editor. So I'll do code doc, and here we are. There you can see

my .venv directory, and I'm gonna add an explore.py. Alright, and I want to install the Twilio Helper Library. So I'll do a Control+Tab, and you'll see that my editor actually went ahead, and ran that argument for me. So I'd already, I'm activated here, which is good, because I want to install a package here using PIP, which stands for the Acute Recursive Acronym of PIP installs of packages. So that's PIP install, and again, Twilio. Cool, so it's installed, and we can start using it. So I'm gonna go up here, and we'll say from Twilio.REST import Client,

and we'll make a new client, and again, it can be instantiated using so here it's given us this nice information that's available about the API. So we'll put a, I'll put in here again, this is our account SID, and boy, it really wants to show us that account SID, and Auth Token. So let's get that. So again, account SID, and Auth Token. Let's get these on some of the new lines by themselves. Again, really bad practice to leave your keys out like this. We'll fix that in a bit. Now let's print out the call log

real quick just to show off the similarities, and differences between the libraries. So the Python version is synchronous, right? So we can say, so we can just iterate through those lists, and messages. So we can say for message in client.messages.list, and we will say print the message.body. Alright, let's see what that looks like. So we will do Python Explore.py and I didn't save it. So that's an important part, Python Explore.py, and there we go. Sent from Postman, Ahoy from terminal. So awesome, So let's go ahead, and we'll comment that out for now, because we're gonna

do something else. So those are commented out, and let's write some code to send a new one. So we'll say message equals client.messages.create, and in here we are going to pass our variables. So we're gonna send this to me, or to you in this case, (503)461-5537. It's my number, and the from, now you'll notice that from is a key word in Python, right? So see like from Twilio? So what's nice is the Python library has made it from underscore here. It helps for the reserved words. So my number, my Twilio number, what was that? Here

it is. That's my Twilio number. Awesome, and let's do a body, and we'll say body, hello from Python. Yeah, let's go ahead, and let's print things out. So Python has a nice little thing called F strings which will allow you to print variables that are in scope. So we'll say if created a new message, and let's just show the message SID to make sure that we got it, and we can just do msg.sid. Hey, so it starts with an F, and it uses the mustaches around this for message.sid. Very similar to those string literals, and

JavaScript. Let's go ahead, and create this one. So we will run Python Explore, and this should send a message, and it did, and again, I want you to see we are abstracting away the fact that we're posting to the messages sub resource under my account. It's just magically happening, because we've logged this client in pretty cool, right? The other thing that this abstraction gives us is we have instance variables that represent our resources. Now, it might not have been clear up here when I looped over these objects, but they're actual objects. It's not just data.

They actually have methods, and I can call the delete method on this message, and it will get deleted. In fact, that's not a bad idea. We've been doing a lot of test exploratory messages. Let's just delete them, okay? So what I'm gonna do is I'm gonna come up here, and I am going to uncomment this code and I'm gonna comment out our creation message code, and let's make this an F string here. So we'll say deleting message body. Here we are. We're gonna say message.delete. Cool. Now before we run this, I want you to make

sure that you understand that we're gonna delete all the messages in your account if you've been using a live account, and have things that you want to save, I highly recommend not running this. Okay, you've been warned. So here we go. I'm gonna update this. There we go. So we've just deleted all of our messages. So if we come, and try to run it again, you'll see there's no messages to loop over. We've done it, clean slate. It's like the nothing never was. Pretty cool, right? That Helper Library was able to abstract away the HTTP

delete call, and it used the information that it had available in its object to make the call itself. Awesome. You see how the helper libraries are similar yet match the development workflow, and style of each language? This is one of the key benefits of helper libraries in general. They abstract the way the HTTP client connection of the REST API boilerplate. They also behave as you expect them to behave. It feels natural. The way that we were able to delete from the resource itself helps to unlock another REST API constraint scavenger hunt item, and that is

uniform design. Now this constraint has four sub sections, one of which is what we just discussed. Resource manipulation through representations, because there was enough information included, it was clear how to modify, and delete this resource. Another sub section in here is resource identification in requests. Those are the URLs that are included, because of the URIs are included, we know that we can get, and manipulate specific resources. Uniform use of the HTTP verbs is pretty powerful. We just wrote some scripts that make use of helper libraries. These libraries are super handy for automation based tasks, or

batch scripting, making a whole bunch of calls at once. When we're talking about this, we should cover another common tool for talking to external API's, and that is the C-L-I, or Command Line Interface. There's that I again. Command Line Interfaces can be used to make API calls from an executable on your machine. More, and more these are showing up for all sorts of tools that require authentication, and do a bunch of different services. This concept is popular amongst cloud providers where setting something up needs to be done quickly from the command line. Check the notes

for more. Another commonplace where you'll use helper libraries is from within applications that you're building. Let's get to the final unit of this course, and implement an external API into existing web applications. You've got this. By now, I hope you're starting to see that external APIs allow you to add pretty incredible features to your applications. Want to send a Slack message when someone fills out feedback on your website? There's an API for that. Want to change the color of your lights in your house when your favorite sports ball team scores? There's an API for your

team, and for your lights if you want it. Want to send yourself a text message 10 minutes before your bus shows up? APIs are there too. Heck, do you want to make a Furby dance? It's got an API. They're everywhere, and give you lots of power. We've seen how to use them from the command line, and we've seen them used in scripts, but now let's take a look at embedding them in a web application. I've gone ahead, and build the starts of web application for us to play with. Now, one thing I know I don't

do enough of is to compliment my friends, and family, and even coworkers. Sometimes the web can be so negative. So I was thinking, what if we made a web app that did the opposite of that? Introducing Complimenter. So the way it works is you fill out a web form for who you're complimenting along with their mobile number. You say why they're great, and they get a text message telling them how great they are, and an encouragement to do the same, and of course they will, and when they come, and see the messages that have been

sent by everyone else, they'll be pleasantly surprised. Pretty sure we have a viral success here. So if there happened to be any venture capitalists watching, that's my phone number there. Now if building, and deploying a website feels a little too much for your current skillset, have no fear, I've created a couple of repositories of code that we'll be using. We're gonna use a fun, approachable tool called Glitch to host our websites. The website is basically functioning minus our API that we're gonna add. If you haven't used Glitch before, it's a collaborative community built around learning.

You take existing projects, and you remix them. It has an online editor. So I want you to head over to Glitch.com, and create a user for yourself if you haven't done so already. After you're all set, let's get to adding our API to the application. First, let's take a look at the Python based web application. We're gonna be using a web framework called Flask. Flask provides an API that lets you extend the framework to create your application. This example application is going to be doing server side rendering. This means that the pages will only be

created on the server side. Any change, or navigation will require a full page reload. In the notes, I've included a link to the repository where I've got our starter code. So go ahead, and copy that. Now I'm gonna open up Glitch.com, and I'm gonna choose New Project. From here I'm gonna choose Clone From Git Repo. In here, I'm gonna paste what I pulled out, and I'm gonna do, this is the one for Flask, so I make sure that's the one that says Flask. I'm gonna click Okay. I've been having a couple of problems with this.

Sometimes this will just sit here, and say loading project. If it does, just try that same thing a couple of times. Let's see what happens here. Sorta times out a little bit. I guess it's safe to say that Glitch is Glitching. Now, that's not fair. There must be some sort of bug that's happening right now. I'm experiencing it. I'm wanting to record this just in case you run into it to just do it a couple times if that happens. I do want to point out that it is pretty amazing what Glitch is doing. It's pulling

us over. It's sending up a whole new environment for us in a web server that can run, and I actually have one that's up, and running. I did the same thing where I made a new project, and you'll notice I'm not even signed in, so that's fine. They let you not even sign in, and create these things. Okay, cool. So here we are. Down here under tools, there's a thing called logs that you can open up, and it will show you what happened. This is what happened though. It's set up our web server here, and

you'll see that the server's actually running, and if you come up here, you can, and click on Show, and the sunglasses here. Your future's so bright, you've got to wear shades. So you can click View in a New Window, and you'll see that the application is up, and running, which is awesome, right? And this URL here, this is all yours, you can use it to do whatever. So the application itself, it's pretty simple. It's just a page with a form, and this section in here, provides messages when they eventually come in, but as of right

now, we don't have any, because we just erased all those, right? But as of right now, we don't have any way to send text messages. We don't yet have the Twilio Helper Library installed in this application. So let's go back over here. So these are the files that are available over here. So you can see here is app.py, and there's some settings that you can do up here. You can come in here, you can actually change the name of this to be whatever you want to be. So I'm gonna call this Complimenter and we'll say

compliment your friends. Cool, and this is another nice thing you can do is you can change the theme. I'll put it on dark theme. I don't know when you're watching this, but this should be okay, both in light, and dark. So there you go. You can also delete this if it's not something that you want, if you ended up creating something. So cool. Awesome. So this app.py, this is our program. Flask works by creating an object called app. So you do this Flask name, and it creates this thing called app, and then what you can

do is you can put different routes in here. So for instance when we go to forward slash, which is the index page, right? It's gonna do a GET, and it's gonna render this template of index.HTML, and that is in here under static templates, index.HTML, and you'll see here, this is how the page is laid out. There's some dynamic data here. We're using some if, and it's gonna loop through messages should they exist, and we'll look at how that works here, and then we'll see there's a form that's doing a post to add compliment. Let's look

back to app.py, and see how these two line up. So it's gonna come in, and it's gonna call, get sent messages, and get some messages is not implemented. I left this here as a to do so we can fix that as it goes. So, and then it basically pushes those messages, and sends us an empty list. It will just go. So in here we can see that there's an add compliment, and it's a happening when a post happens. So it's gonna run this function when a post happens, and again, that post was happening from the

form, and we'll see what's happening is it's just pulling off these variables is we've got sender receiver compliment that's pulling off a two, and if we take a look at 'em back out here, if we look at our form, we will see that we've got, there's the two, and you'll see the name is two. So that's what's getting pushed across, and their sender, and receiver, and compliment. So they're pulling us through. It's kind of building a message for you. So sender says, and she's using that F string right? Sender says receiver is compliment, see more

at request.URL, and we'll send that message to body. So it's gonna call, send message, and right now send message is needed to be filled out. So this to do here is actually a pretty good place to start, right? We need to send the text message, otherwise there's no messages to show, and we know how to send text messages using a RESTful API, no sweat. We can do that. So I could use the Python HTTP client, and write my own messages. That seems like a lot of extra work, right? So I'm gonna use the Twilio Helper

Library. So in Glitch you can access the terminal from your application by down here. If you go into this clip tools, and you come up here to logs, and then come over here to console, and see that I've now got a terminal running, which is pretty powerful, right? So I'm gonna type source. and then it's .venv/bin/activate. And remember we had done that before. So we're gonna activate script now we're activated, and you'll notice that I've got this this year, this venv. So now I will go ahead, and I'll do a PIP install Twilio. So we'll

get down that Twilio Helper Library so that we can use it in this application. Awesome, so it's all installed. So we should be able to use that. I'll go ahead, and close this, and it went, and it downloaded everything that we needed, right? So it got it, but if someone was to come along later, and use it the way that it knows what to install is there is this requirements.txt file, and you'll notice the Twilio stuff isn't in there. This is just got the stuff for Flask, Jinja's part of Flask, and Werkzeug is also part

of Flask. It's got just the stuff that was needed so they won't have the Twilio Library. So we want to get the Twilio Library in here. So the way to do that is let's get back in here into the console. So first again, we're gonna activate source/venv/bin/activate. Okay, so we're gonna use PIP freeze to show all of the packages that we have installed, and then we can store its output, and we can do that in this requirements.txt. I'm gonna go ahead, and do that, and when you make a change in the console, you have to

do refresh to make sure that it shows up. So now if we look in here, we will see that we have Twilio is now available for whoever comes to use this later. Cool, let's write some Python. Okay, so back in app.py. I'm going to come in here, and I'm gonna say from Twilio.rest, import Client. So this line here, this load.env will load environment variables from a secret Glitch file that I have over here this .env. I started it for you. Now why don't you pause me, and go get your keys, and phone number, and fill

this file out. This is kind of like the environments that we saw in Postman. So go get those. Do you know where they're at? Go ahead, pause me, and when you're already unpause me, and I'll show you how I did it. Ready? Okay. So here's how I did it. I wait till my Twilio console, and I copied my account SID, and then I went, and I went to my Auth Token, and I copied that, and I pasted that there, and then of course my TWILIO_PHONE_NUMBER is my trial phone number right here, and I'm gonna paste

that here, and save that, except I don't need that. There we go. Cool, so let's flip back to app.py. And if we take a look here, there's a thing called TWILIO_PHONE_NUMBER, and it's using this os.getemv for a GET environment TWILIO_PHONE_NUMBER. So it's pulling that from here. So in our application, automatically this will be set up. Nobody else can see this. This is your personal information, but here I've got that stored in a variable. Pretty cool, right? So let's go ahead, and let's create one of those clients, right? So we'll say client equals client, and here's

a little fun fact. If you don't pass any arguments to the client object on creation, it will look in your environment variables for those Twilio underscore values. So like the Twilio account SID, so environment variables are an excellent way to keep your keys hidden, and not leave them sitting in the front seat. Check the notes for how to do that locally on your machine. So now we have an authenticated client that we can use to complete these to-dos. So the first one I think we should do is tackling that, sending the message, right? That was

down here. We're gonna send this message, I'm gonna come in here, and I'm gonna delete this keyword called pass. And I'm gonna start with actually, you know what? You got this. Go ahead, and write the code to send a message. Now don't worry if you didn't memorize the syntax, I've put links in the notes to the Twilio docs ready? Pause me and write the code to send a message using the to, the body, which is come here, right? So we've got the two in the body coming in, and all you need to do is set

the from, and you can set that from your Twilio number here. If you do it right, and fill out the form, you should get a text to your phone number. You've got to text your number. So a couple of gotchas in Python spacing matters. So make sure that you're indented under the function. See how this is indented here? Make sure you're there, and remember that from, F-R-O-M, from is a keyword in Python. So it's from underscore, right? You ready? Go ahead. Write some code to send a message, pause me, and then I'll show you how

I did it. Ready? You got this? Okay. How'd you do? So here's how I did it. So I use the client, and I use messages create, and I passed in two, and that's the, what's coming in from the function there, and the body is also what's coming in front of the function there, and then I had to use from underscore, and I'm gonna say the TWILIO_PHONE_NUMBER. Awesome. And I'm gonna click the Show in a New Window. Cool, so we're gonna text my number here. So that's plus 1-053-461-5537 and we're gonna compliment me. Person to compliment

is Craig, we're gonna say Craig, Craig, is completing to-dos and we're gonna send the compliment, and I should get a text. It says that my message was sent successfully, and awesome. I got it, and now I'm gonna remove that to do, I'm gonna feel good. I love removing to-do's. There's nothing, nothing better than that. So what do you say we get the next one? Let's do it, we can do this. Make this return a collection of messages that were sent from the number. Should we do it? Let's do it. So get sent messages is used

in this index function, right? So that's what's pulling out the messages. So let's take a look again real quick at that template. Yeah, so it's saying if messages, if there are any messages for message in message, write out the message body. So that's gonna just loop through those messages. So we are going to pass through the message object, a list of those message objects. So in this GET sent messages, we see that it's an empty array, so that's why it's never showing up. So we want to replace this with a call to get the client

call log, right? Do you remember how we did that? Okay, you have the link to the doc. So go ahead, give me a pause, and see if you can't get it. If you get it, and refresh the page, you should see the message, and recent messages. Ready? Pause me. I'll show you how I did it after you unpause. You've got this. Okay, this is how I did it. So I used client.messages.list, and remember we could be using an account that has multiple numbers. So we really only want to get the messages that were sent from

our Twilio number. So again, that's from with an underscore, and we'll do TWILIO_PHONE_NUMBER. So that's a way of querying that, right? So we're saying we only want messages that were sent to the TWILIO_PHONE_NUMBER, and if I come over here, and refresh, there it is. Craig says, Craig is completing to do's. See more compliments at HDP complimentary.Glitch.me. So yours will be whatever yours is there. Pretty cool, right? Great job getting that application up, and running, because it's actually running. You could totally share that out now by sending a text message to someone you trust. Wait, well

actually, maybe you can't. I seem to remember something about our accounts being limited verified numbers only while in trial mode. Now, API limits are probably something that we should look into really quick, since they're pretty common with every API that you might encounter. Let's take a quick detour, and explore some limits, and then we'll get right back to implementing this app in a full stack JavaScript app. APIs are designed to have limits. As you can imagine, if you were the maintainer of a web based API, you wouldn't want someone making millions of requests in a

short period of time. The chances are your API server couldn't support the load. The typical solution to this is the throttle, or limit the number of requests that you can make per second. Typically these limits are introduced when you get your API keys. If you'll recall on the Twilio console where we got that trial number, we were informed that not only will messages we send during the trial have that trial text that we'd been seeing, it also said that we can only send a verified numbers. What do you say we see what happens if we

try? Now, I don't know about you, but I find that having people that support you in your life to be super important. Now for me, hands down, that person's my mom. Like no matter what I'm doing, she's just there in the sidelines cheering me on. Whenever I launch something new, you can pretty much guarantee that she's helped me test it out. So I'd like you to do this. I'd like you to think of someone like that in your life, and I'd like you to send them a compliment using Complimenter. So I'm gonna add my mom

here. So I'm gonna add her number, and that is 1-602-609-5813. So used to just pressing mom on the phone, right? So I'm gonna say my name is Craig, and I'm complimenting mom, and mom is infinitely supportive as you'll soon see, I'm sure. So obviously you should put in your friend, or family or colleague here. Here we go. Alright, so I'm gonna click Send compliment, and ooh, no, internal server error, yuck. Let's go, and look at our logs, and see what happened. So I've got a pretty big stack trace here of what happened on add compliment,

and if we come down here, it says the number is unverified. Trial accounts cannot send messages to unverified numbers. Oh, right, verify. Oh, we can verify them at Twilio.com/verify. Let's go ahead, and do that. Can I can do that? That's cool. Go to awesome. So now I need to get my mom's number in here. I need to get her to be verified so that she can see it. So you can actually do this pretty easily, and what this will allow me to do is to be able to have my trial account be able to text

her, which is all we need, right? So what I'm gonna do is I'm gonna click Add, and they will call you with a verification number, or I'm gonna make it text you instead. So what I'm gonna do is I'm going to put in my mom's number here, put in (602) 609-5813. So what I'll do now before I click the Text Me, is I'll say, hey mom, I'm texting her this it's me again. Hey, I'm going to verify your number. You're gonna get text from Twilio. Can you send it back to me? And she wrote back.

Sure thing sweetie, aww. Okay, so now that I know she's ready, I'll now send that validation message, and so I'll click Text Me, and I will wait for my mom to tell me what that was, and then she should be able to send me the code. Okay, so she texted me, and that number is 946541, and then I click Submit. Awesome, so now my mom is verified. Here she is. She's in this verified numbers. Now I can text her now let's go try that again. Let's get back to this internal server error, and I'm gonna

refresh. Reload that, and it's gonna say you're gonna submit the forming, and that's totally fine. That's what I want it to do. It's actually what I want it to do, and we say continue, and boom, we did it, and my mom should get a message, and she did. She just sent me an emoji heart. I hope you're now able to show off your app to your supportive person. It's really nice to have that support as you're learning, and building things. If you don't have someone like this. My mom's pretty supportive. If you want to just

text her, I bet she'll shoot you back some words of encouragement. No, of course this app isn't gonna go viral in this trial mood, but this is a great prototype of the concept. Most of the time APS will give you a chance to get your prototype together before they start charging you, but being aware of the limits will help you plan your efforts. Remember to carefully read the limits, and error messages. Most API will guide you into how to deal with limitations. Now let's get started with a JavaScript based implementation of Complimenter. Now we're gonna

implement that same Complimenter application, this time using JavaScript. I've got a full stack JavaScript application mostly built, and ready for us to tweak. By full stack JavaScript, I mean the server is written in JavaScript, and there's some front end code that's also written in JavaScript. On the server side, the application uses Node.js, and the web framework express. On the front end I've used the client side framework view. The Python version that we saw earlier was all server side. There is some things to consider when implementing a client side application when using an API. So let's

explore those while we get this JavaScript prototype up, and running. In the notes, I've supplied a link to the repo that you can use to create the new Glitch project. Go ahead, and copy, and paste that. I'm gonna click Clone From GET Repo, and then I'm gonna paste the repo. Alright, so we're gonna do the Node version. So this is Node, and again, if Glitch takes a while to spin up, that's okay. It might eventually show up, or it might Glitch out, and if it does Glitch out like this, like sometimes I might just say

the assets folder, just go ahead, and do it again, and it'll eventually work for you. Awesome, here's mine working. The JavaScript version of this project is implemented as a very simple Single Page Application, or SPA, and what that means is that once the page is rendered, the client will responsible for rendering parts of the page. We won't rely on a full page reload from the server to load new pages for us. Let's take a look at app.JS the server side of our application. So we're gonna look at app.JS. So let's see this first .env here.

This will load up our environment variables, which we'll take a look out here in a second. Then it's using express, which is a web framework, and you'll note that it's exposing static files in a public directory. So this is a single page application, and it's rendered in publicindex.HTML. Let's take a look there, Publicindex.HTML. So this here is the view dependency. If you haven't seen view before, no worries. This is a pretty straightforward way of using it. So what View does is it uses these V dash, right? So it's these V dash attributes, and those are

view specifics. So basically this is saying if the compliments that length is greater than zero, and we'll see how compliments is defined here in a bit, and as you can see if it does exist, it's gonna loop through each one of the compliments, and then it's gonna write them out. So it's gonna write them out using that double mustache syntax here. So it's gonna write out the compliment that's in this loop. Okay, so that compliments variable is initialized in our application. Let's scroll down to it. I've put the whole application in one single file here.

So we don't need to worry about packaging, or anything. So the way that you create a new view app is by saying new view, and you can see here there's this data attribute, and as you'll see, compliments is initialized as an empty array. You can add instance methods to your application by adding a methods object in the view constructor. So we have a method here called refresh compliments. Now you might not have seen this before, but if you've had a hard time keeping track of promise based codes in the past, this feature here is the

one that you've been waiting for. You'll see here that the keyword async is before the name of the function. So it says async refresh compliments. Once a function is labeled as asynchronous, you can now cause functions that return promises to behave synchronously. Meaning they don't move on to the following line until it completes. So this line here makes a fetch, right? So fetch returns a promise, but there's a keyword here of oh wait, right before it, and this code will wait for the fetch call to complete, and then assign the future value of whatever this

is into the response. In the same is true here response that JSON returns a promise, and this will wait until this is done. One thing to note is that this async function makes it so that refresh compliments now returns a promise. That is it's return value will have a then method that returns this value. Now if that doesn't make sense just yet, just you await it will. Just try, and let it all async in. A dad joke, double whammy. Sorry, I'm kind of obligated to make all these jokes. Really though, most devs that I talked

to find this async await more straightforward to use than promises for code that's actually synchronous in nature. Alright, so what is this code doing? So it's making a GET request. Fetches default method is a GET to a URL of /API/Compliments. So that's in our server side code. Let's flip back to here to app.js, and you define routes with express using this app.GET. So whatever the HTTP method name is. So app.GET/API/compliments, that's what we saw. So when that happens, this function here will run, and we'll pass in the request, and the response, and here's our first

to do so we want to get the message log. So first before we do that, we better install the Twilio Helper Library using NPM. So I'll click on Tools, and then I'll click on this logs, and then I'll click on Console. Now I'm gonna run NPM install, install Twilio, and I'm gonna do --save. What that will do is it will update a file called Package.JSON after it installs, and this is much like we saw in the Python library, we did the freeze, this --save will update that file so that the Twilio dependency is there. We'll

let this complete. Awesome, and so now when you make a change from this side, we always need to say refresh so that we can refresh the project, and see the changes that we made, and so if we look in here under package .JSON, you can see that there is a dependency of Twilio. Great, so now that we have things installed, let's go ahead and update the in the .env file. So that's this key. See this little key.env here? This is gonna allow us to put our information in here. So I'm gonna go ahead, I'm gonna

grab my account SID. You should do the same with yours, and grab my Auth Token, and last, but definitely not least my phone number. Alright, and now we can use that in our code. Let's go right above this port. Right below this port here. We'll make a new Twilio client, and we'll require, actually that probably looks better up top a little bit more. Let's move that. Let's do that right. This is all out of alphabetical order, isn't it? Let's do this right here. Here we go, and then we can instantiate one that will look better

down here. So I'll say const client equals new Twilio client, and again, it's gonna pull from the environment variables of the Twilio underscore, and just to show you how you do that here. So we'll say const the TWILIO_PHONE_NUMBER. If you ever wanted to pull something else out of the environment, you use process.env.thething. So the thing was called Twilio, I think it's called phone number. Let's double check TWILIO_PHONE_NUMBER and env.TWILIO_PHONE_NUMBER. Yeah, cool, awesome. So let's get that message log. So what I'm gonna do is I'm gonna replace this. So we're getting the compliment. So we're getting

sent messages. So this to do get a list of messages sent from a specific number, obviously Twilio number there. So what I'm gonna do is I'm gonna replace this array with my code, and actually you want to give this a spin? Well, one thing to note is that the function is marked async. So you can, and you probably should use the keyword await, right? So this is an async function. So make sure you use the await keyword. Are you ready? Just make the call to the messages API to get a list of messages that were

sent to a specific number. Like the to-do says. Don't worry if you don't have it memorized, I put a link to the docs in the notes. Go ahead, and pause me, and give it a shot. When you unpause me, I'll show you how I did it. Ready? How'd you do? So what I did was client.messages.list, and in the JavaScript Client Helper Library, you pass in an object with the parameters. So we say from not a key word here, and we'll say TWILIO_PHONE_NUMBER, and like I said, we should make this be a wait, because we're gonna

wait for that to happen, and boom, just like that of that to do, well, why don't we change? Why don't we take a look, let's go. I'm gonna change this to be Complimenter of a mentor that's not very nice to Complimenter.js. Compliments, I'm gonna close that, and let's go ahead, and we'll do show when we should see the messages come through. Oh, we shouldn't see the message come through yet, right? Because we aren't passing anything through. We're passing down these compliments. Alright, let's see. Let's see if we can get this next to do done them.

Gather only the body of those messages for sending to the client. Okay, oh right, because we don't want to send down the whole message object to the client. So what we want to do, the API is called compliments, right? And we have an array of text messages. So more importantly though, if I were to send down this message, each one of those messages, it contains a bunch of informations that I don't think we want to share with everybody. That message has the phone number of the people who sent the message. I should never send information

that I want to keep safe down to the client. So really we only want the body. So let's see, I have an array, and I want a new array of just message bodies. Now to me, this sounds like a great use of the array.map function. So sent messages is an array. We'll say sent messages.map, and the map function, map takes a function that will receive each value in the array. So that will be a message, and it takes a function, and if it's on one line, we can skip the return keyword, and just put what

we'd like to see. So this compliments array, we want to see the array of message.body, right? So what this is saying is like for each of these messages in here, just return the message body, and put it in compliments. Makes sense, and then it's gonna send down the JSON representation of that to our view client. Should we see if it works? Alright, we'll save this, and now, oh, there we go. It's working already. So we'll see. There's a new one from my mom, and it says, mom says, Craig is so proud of you, sweetie. Oops,

it's nice, it's sweet. She wrote back, and that's what I love about having someone use your applications. It looks like I still have some UI work to do to make it more clear about what's happening, because my mom wrote so proud of you sweetie in the compliment, and that doesn't make much sense, but I feel nice, and again this is using the number, this was not sent from this app. You can see it was sent from the Python app, right? This is Complimenter.js, but this is using a different data source, and you know what? While

we're here, why don't we look at how easy it is to see what the data was that was sent down from the server? So I'm gonna right click, and I'm gonna choose Inspect. I'm gonna click on this Network tab here, and I'm gonna refresh the page, and you'll see it make that request. So if I click on this Compliments here, you can see here is the message. Here's that array that was sent down, right? You can imagine that if we sent down all of those messages, we'd have that data very easy to get. So again,

this is the developer toolbars if you say View, Developer, Developer Tools, you'll be able to see this. I'm gonna take a quick break, and then I'm gonna swing right back, and finish up the remaining to do, creating a new compliment. (calming electronic music) We just finished displaying a list of all the compliments, and now it's time to deal with how they get added on the JavaScript side. So let's keep the front end code, and see what happens. So that is in publicindex.HTML. So here's that form. Alright, so we have this it's a form that goes

to post. It goes to /add compliment, and it's got these V dash models. So here's like V dash, model two, Videsh model sender, and that's how view does data binding. So anything in that field will be bound to that variable, and if we come down to the button here, we will see that the normal click, it won't, it will prevent, right? So that prevents it from being submitted, and it calls this send compliment method, which is defined in the method stanza here, which is this send compliment. Okay, so it goes ahead, and it grabs the

stuff from the form so it pulls them all off. They also happen to be the same, it's in a thing called data, then it uses fetch, and it uses it synchronously, right? So it's got an a wait, it's gonna wait for fetch to go, and it passes That as JSON, and were saying that it is JSON, and we're passing JSON up, and we're doing a post request, and let's go ahead, and we'll take a look in app.js, and we'll see here that we're using this body parts here, so any request that comes in will automatically

get parsed, and the way that that looks is a, so here's this post, right? So here's, we failed, we fixed this get, and we got to get rid of these two do's. Forgot to erase those. Those are to-done. Alright, so it comes in here, and it's posted to API compliments, again, an async method. So it's gonna pull off of the request body too right? So, and because of the body was parsed, it's automatically inflated here. So body the two, it's gonna pull the two off of the field, and request that body sender, or Costa biosphere,

very compliment, and it's using the Bactec so it's automatically filling those out. So here we are. Here's our to do. Why don't we just synchronously create that message? Well, you want to give this to do a try? Go ahead, pause me. I put links in the notes, I'll await for you to unpause me, and then show me how you did it. How'd it go? Here's how I did it. So we want it to be synchronous. So I'm gonna go ahead, and use await, and I don't really need anything from the create a message, so I'm

not gonna assign a return value, and I'll use the fact that the parameters are the same. So I'm gonna say client.plant.messages.create, and in JavaScript you can do this. If you have a variable named two, it will just set 2:2 from embody, right? So this is just basically, because there is a variable called two, it knows to make a new one called two in this array here. Alright, so let's give that a go. So I will go ahead, and click Show Here, and I'm gonna send another one to my mom. To mom, no, my name's not

mom. Well my name's Craig, and I'm gonna compliment mom. Her compliment is a really patient tester. Mom is a really patient tester. So here we go. Yep, there it is. So see right away it came back, and you'll see that the forms cleared. So let's see how it did that. So back in the index.HTML we have this, we posted it, and it got back the data, and it awaited for the result, and then it wrote out the result, and we saw this information come down. So we could actually, if we wanted to, we could do

View, Developer, Develop Tools, and we should see in the console. Here's the object that got sent back. So it was a success of false. Now, we forgot to update that, didn't we? I'll have to look. I thought we looked at that. Now, if you're gonna say, yeah, that was a successful journey there. Good job. Glad we caught that. Speaking of catching stuff, what happens if things go wrong? So much like before when we needed to capture the error using the catch method on promises, we need to do something similar in this async await land. So

we need to use a standard try catch block. Now if you haven't seen that before it's, it's pretty straightforward. What you do is you say try, and if any error at all is thrown what will happen is it will call this catch block, and it's a good way to handle errors. So we're gonna catch that error. So the error object has a status, and you can send that down to the client by saying response.status, and we can do error.status. We'll just pass that status straight through, and this is changeable. So we'll send JSON, might as

what happened. So we'll say success is false for real this time, and we'll also send, why don't we send the message, we'll send that error error.message. There we go, and you know what? We can use prettier here too. So we're gonna click this format, this file. Let's make this thing prettier. Ooh, nice. Okay, so we're going to try, and if there is a failure, we're gonna send this back, and then otherwise we're gonna go ahead, and send down the success of true. So we got to break it somehow. How should we do that? Let's say

instead of from, let's make this be 42, the meaning of life, and everything. So that is obviously not a valid TWILIO_PHONE_NUMBER. So let's go ahead, and let's bring up Complimenter, and I'm just gonna oh, it did refresh. I was gonna refresh it, and it did for me. So we'll send another message to my mom. My name is Craig to my mom, and the compliment is good at catching errors. Okay, and I'm gonna click Send a Compliment. Let's see what happens. Oh look, so here we got the error. It's a 400 that came back, and the

from phone number 42 is not valid. CMS capable, or inbound number, or short cover from your account is a better version of it. Cool, right? And let's make sure we don't leave that in that state. So we'll undo that, and save it, because I want my mom to give me another compliment. Again, we are good to go. Awesome job. You've now used an external API in two completely different web frameworks, and paradigms even. you should be sending a compliment to yourself. You're accomplishing great things. Way to stick with it. One other thing I'd like to

take a quick moment to point out is that the server code that we wrote, you might've noticed it was prefixed with a /API server code that interfaced with a client. Now here's my question to you. Do you think that the API code that we wrote together should be considered RESTful? Why don't we take a look at our weathered scavenger hunt card? So it's definitely a Client-Server Architecture. Our client happens to be, in this case, a view application running in the browser, and our server is a Node.js server, but any client could connect, and use this.

It's definitely Stateless, right? We aren't requiring any prior knowledge about the client. Well, at the moment we aren't providing any caching information so we could, right. We could fairly easily pay attention to those headers coming in, and respond appropriately. It would require us writing some additional code, and thinking through some edge cases, but we could do it. Let's put this in the maybe column. Yeah, for sure, right. In fact, it's a little layered already. Our API is calling another API, but our client doesn't need to know that. We could also add additional functionality, and the

contract wouldn't change. We haven't even talked about this one yet, and it's the only optional requirement. Now basically this means your API returns code that is runnable, like maybe it returns an embeddable widget, or some actual JavaScript code. This doesn't make sense on our application, and that's okay. I'm gonna drop this one in the no, so we're looking good so far, but here comes the doozy. So remember this one has four subsections, rut row. Currently we're just representing all the complements as strings, and absolutely no way to identify them. So we fail this sub requirement,

and therefore this thing is a no, but let's keep going through the rest of these. Pun intended, sorry. We definitely do not allow any sort of manipulation of compliments. So this is another fail. We haven't gone over this yet, but by using headers we can tell that this is JSON. The message sent down has a type, and it is clear that it should be JSON decoded to be used, and last, but certainly not least, Hateos, or Hate OS is an often forgotten about part of the RESTful constraint, and very hard to say. The idea here

is that there are links provided to show off what more you could do with this, and where you could find related resources. It provides URIs, or links. We did see this in both the Spotify, and Twilio ones. However, ours doesn't need to provide links to other resources. So we don't have a RESTful API, and that's okay. It works as is. It does look like we could get there pretty quickly if we wanted to. One thing I want you to gain from that exercise is that you now have the ability to identify whether, or not an

API is RESTful, and I hope that felt pretty good. We've now completed that scavenger hunt. We revealed all the constraints, and I hope that most of those are pretty clear. Please don't feel like you need to memorize those. You can find these same constraints littered all over the internet as a prize for finishing the constraint scavenger hunt, I've dropped links to my favorite REST API constraint documentation for you to lean on. I've also included links to popular REST API frameworks that will help you design RESTful APIs. Make sure to check the notes. You did it.

You just completed a whirlwind introduction to APIs, and I hope you see how much power they can add to your programming journey by looking at interfaces in general. I hope you're more comfortable with the idea of not fully understanding exactly how something is working, but still leaning on that abstraction to build your tools, and applications. We do this all the time with physical object interfaces, and APIs, or Application Programming Interfaces aren't all that different. I hope you enjoyed taking this course. I know I had a ton of fun making it. If you think someone you

know might benefit from this course, share it with them. I'd love to hear your feelings, your thoughts, and your dreams. So I threw together a little something using a smattering of API's to capture your feedback. If you've got the time, I'd love to have you answer a quick text based survey. Text feedback to 1-503-461-5537. Actually, you know what? If you want to, you can also just call, and leave me a message too. I used an API for that too. Please, please, please keep me posted on your journey, and really I can't wait to see what

you build. Thanks for hanging out. (calming electronic music)