– 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).