If we want to welcome back Johnny be here with slopes stock and in this lesson we are going to talk
about something that is extremely important for developers to understand and that is web requests.
You'll be hard pressed to find an app today that does not use requests in some form whether it's Facebook
or Twitter or Spotify.
These are all communicating with a server via web requests to get you the information that you are seeing
in your apps.
OK.
So let's just start out with what you see on a Web site.
Let's say you go to Devis slopes dot com and you see this beautiful Web site.
Well how on earth is this actually done.
How does your Web Browser know what to display when you type in slopes dot com or Google dot com or
any Web site.
First off let's talk about something called HTP stands for Hypertext Transfer Protocol and you probably
recognize this because it's at the front of all your Web site domains right.
So it's a protocol or a standard.
So what we know is that this Web site is abiding by this standard.
And so we can use this Hypertext Transfer Protocol to send or receive information in a text format and
we're sending that information between clients like web browsers and apps and servers where all the
specific information for that Web site or API is stored.
OK so let's see if we have some clients here we got an iPhone Android phone.
A web browser.
And we want to go to dev slopes dot com.
Well those slopes dot com has content hosted on a server.
And when the user types in dev slopes dot com into their device the client is sending an HTP get Web
request to a very specific address on the server meaning we are basically just saying hey we want to
see what you got and the server can take a look at this TTP kit request and say yeah OK I'll show you
what I got.
Then it can return and HTP response that contains information like headers and the body and the body
is going to have all the symbol and the browser then takes that and turns it into the Web sites that
you see.
Now let's talk about web requests from an app's perspective specifically our chat app.
So here in a few lessons we're going to be working with our chat API and API stands for application
program interface basically an API is code that is hosted on a server or locally that can receive web
requests process information and take action based on that request whether it's returning information
storing data in a database or any number of things that you can program an API to do.
Our past courses.
If you have taken any we have used a number of API including the pokie API to get pokmon information
as well as the open weather API guys to get weather information.
And in the case of the API we are going to be working with.
It handles things like creating and authenticating users fetching messages and channels and account
information and it stores all that information in a separate database.
So the API is code that interfaces with the client returning information and sending data from the database
as needed.
Now let's shift gears a little and talk about the type of information that is typically returned from
an API.
We've talked about the get request with Web sites and servers.
In this case the site usually returns a mail which the browser converts into pretty pictures and text.
Most API these days they'll return what is called Jaison which stands for javascript object notation.
So when you send a web request to an API instead of getting back HD and now you get back.
Jason and this is what Jason looks like.
It's actually not too bad to read.
This is a sample from the chat API and these are chat messages.
The curly brace denotes the beginning of a J song object which consists of key value pairs.
The key is always a string which is paired with a value that can be a string a number a boolean an array
or even another chase object.
So the app makes a get Web request to a specific URL something like w w w dot chat API dot com slash
message slash by channel slash general.
And then the client gets back this Jaison on data that the client then parses out and displays to the
user like you see here.
Before we move onto the other types of web requests I want to discuss real quick bodies and headers.
So there are bodies and headers in both requests and responses.
A common thing with API for security is to have an authorization token or an API key.
This is a security measure to make sure not just anyone can access the API and get data in our app.
We let anyone create a user but once a user is created that user gets an authorization token and that
authorization token is sent as part of the HTP get request in the form of a header.
So the AP receives for instance a chat messages get request and first thing is going to do is check
out the authorization token in the header and make sure it's valid.
If it's not it's just going to kick back that request within an unauthorized request error.
So that's the get request.
Now say we are sending a chat message.
And so this is also done in a web request.
But this web request is called a post web request meaning we are sending data inside our HTP request
that the server can do something with.
So in addition to our web request having a token header there is also Giese on data inside the body
of the post request.
This chase on object contains the message itself.
Who sent it.
The user and any other info we need the API will again check the token in the header.
Make sure it's valid except the chat message info in the body and turn it into a message object and
send that message over to the database to be stored.
Other web request types are put which alter an existing object for instance.
This could be used to change the user name of an existing user and there is also the delete web request
which is used to delete existing objects.
Lastly I want to talk about where the sockets come now when we look at these types of requests that
we've already talked about.
They are all one time user initiated requests right.
It's like every time we need something we have to go knock on the API door show them our credentials
and then they'll give us what we need.
Well that doesn't really work with something like a chat app does it because we don't know when someone
is sending a message so we don't know when to go and ask the API for you know all of the chat messages.
So what are we supposed to do.
I send an API request every one or two seconds.
No don't do that.
That's bad bad.
So what we need are Web sockets if the if the requests that we've been talking about is like going and
knocking on someone's door every time you need something web sockets is like an open door policy free
flow of information in both directions.
Right.
It establishes So what it does is it establishes a two way bridge between the client and the server.
This way when your friend Billy sends you a check message to you on his iPhone that will go right to
the server and then all right to your phone because we have that web socket set up.
We have a open flow of information between all of the devices connected to the server and the other
devices.
OK.
So it's pretty cool stuff.
It's going to be really fun and pretty easy to implement so I'm excited to get you guys going on that.
Yes so that's how web requests API eyes and web sockets work from a high level.
And the next lessons we are going to get our hands dirty and really see how they work starting with
setting up our own API and databases on Heroku and labs.
So I will see you in the next one.