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