Alright friends, let's talk about headers within our REST APIs.
So the first header that I want to talk to you about is one called an accept
header.
So let's just quickly draw out the scenario over here we have our clients, okay
?
And over here what we can do is have our server.
So the client is going to make a request to the actual server here as it does.
And as we know it's going to be using HTTP or preferably HTTPS.
Now in this request if we specify an accept header,
what we can do is specify the value and tell the server the type of data that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
what we can do is specify the value and tell the server the type of data that
we are willing to accept
as a client. So let's just say this server happens to have a whole bunch of
information about,
oh I don't know all the devices within a network topology, okay?
All that information is stored here, the type of devices, the IP addresses, the
interfaces,
so on and so forth, it's all in there. The client here wants to get that
information.
But let's maybe say we want to tell the server hey, the type of information I
want is I want this
coming back to me formatted in JSON. We tell the server the type of response WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
coming back to me formatted in JSON. We tell the server the type of response
that we are willing to
accept a JSON based response. And then for what, for reason, let's maybe say
that we make a request,
and this time we want to get the response back for whatever request we have
made,
depending on the URI. We want the data coming back to us in XML. Once again, we
can tell the server
what we're willing to accept via the accept header, really quick
straightforward.
Now let's suppose we wanted to do something a little bit different, okay? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now let's suppose we wanted to do something a little bit different, okay?
So now as opposed to the client making a request to a server and saying hey can
I get back some
information in JSON or XML, what if we wanted to modify the contents within a
server? Well,
we can make a post request as we do not create any resource. Now at this stage
here,
along with the request, we're going to actually have to send some type of
payload, which is going to be
the data that we're trying to insert into the server. Now because we are not
just making a request,
it simply retrieves some information from the server, but also including WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it simply retrieves some information from the server, but also including
content of our own.
What we want to do is we want to tell the server the type of content to expect.
Now the way we do
this is once again via header, this time known as a content type header. Now
consider this again,
client server. Let's imagine we have some very sensitive data on this server,
okay? Now think about it,
should this client be able to just reach into this server and read this
potentially sensitive data,
or maybe even modify this sensitive data without really having to prove who WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or maybe even modify this sensitive data without really having to prove who
they actually are to
prove their credentials, so to speak. Not really, this would be a pretty bad
idea. So what we can
actually do is pass on the credentials via an authorization header, and this is
exactly as it
sounds a way for you to authenticate with the server you're trying to talk to.
Now one crucial point
to note is that you don't have to use one of these headers in place of another,
you can actually use
multiple headers together. So you could pass in your authentication credentials
within the authorization WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
within the authorization
header, and at the same time specify a content type, you know, saying I'm going
to be sending you some
JSON data. And now the server knows to expect JSON data, and the server also
knows that the client
is actually allowed to make a request because they have been authorized. This
is a type of thing
that we do with our headers. Okay, now next point, this is a really important
concept, because we're
dealing with rest, we're dealing with HTTP, and HTTP has some very specific
response codes. Essentially,
what I'm talking about here is when our client goes and sends off a particular WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
what I'm talking about here is when our client goes and sends off a particular
request to the server.
The server is always going to respond with some type of response code, now this
is going to be a
three digit number that ultimately describes the state of the request itself.
So three digit number,
let's say the first digit starts with a one. Okay, let's forget about the last
two digits right now,
but let's just say if it starts with a one, this is a particular class of
response, and this class
of response is known as an informational response code. Essentially, this is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of response is known as an informational response code. Essentially, this is
the server's way of
saying to you, hey, I got your request. It is valid. There's no problem here,
but I'm still waiting for
some information. Now the next two digits, they actually tell you what is
happening with a little
bit more specificity. So say, for example, you receive a 100 status code, the
first number here
tells you again, it's informational, but the remaining two digits, this
actually correlates to a
very particular response. What this response actually means, it's the way of
the server telling the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the server telling the
client to simply continue. So you can imagine if the client was sending a ton
of information to the
server right here, and basically you want to assess that the server is not
actually rejecting anything,
and we just want to be sure that it's ready to continue and process more
information. Then we
can wait to get this 100 status code. And if we do get that, then that
indicates that everything
is as expected, and then we can continue on sending more data. Whereas if we
get the next class of
status codes, this is going to start with a two. So if your response happens to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
status codes, this is going to start with a two. So if your response happens to
begin with the number
two, you should begin clicking your heels and celebrating what this actually
denotes, is that we have
had a successful request, everything is as expected. Okay. Now once again, the
first digit tells you
the class is successful, but the next two digits tell you very specifically
what the success was.
So again, let's imagine we have our client over here and the server over here,
and we happen to
send, let's go with an HTTP get request, that's the method we use, and we have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
send, let's go with an HTTP get request, that's the method we use, and we have
our authorization
and play, we have our accept header, so on so forth. When the server actually
sends back the data
we were looking for, we're also going to see in the response the status code of
200, and a 200
response is just correlating to okay pretty much the server is saying to you,
everything was good,
no problems at all. So this is what we can expect with the get request, however
, let's imagine
things were a little bit different. We then send a new request to the server,
this time we send
a post request, so again we will have our content type headers, maybe we've got WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a post request, so again we will have our content type headers, maybe we've got
our authorization
headers, and the data that we're trying to insert into the server, this has
been accepted, so what
we're going to do is we're going to get a response back and in that response we
're going to see a
status code, and once again, as you may expect, that status code is going to
begin with a two,
this time though, the next two digits are going to be 0, 1. This particular
status code denotes
that we have a success, but also that a resource was created. So you wouldn't
expect to see this
status code with the get request, which are not creating a resource, but for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
status code with the get request, which are not creating a resource, but for
something like say a
post request, this is the type of response you would want, and all the server
is doing here is
giving you really clear information. So three more categories, let's blitz
through them then,
once again we send off a request to our server, the server responds this time
with a status code
beginning with the number three, what this class of status code denotes is that
we have a redirection
okay, so let's imagine we get a 301 status code again, three tells us it's a
redirection, and a 301
tells us is that the resource we're looking for has moved permanently okay, so WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
tells us is that the resource we're looking for has moved permanently okay, so
the thing you were
looking for is not at that end point anymore, if you want to get it, well you
're going to have to
make a modification, whereas if we happen to maybe get a 307 response, this is
actually telling us
that the resource has moved temporarily, so perhaps if you wait a little bit,
resend the request,
maybe you will be successful, so again the difference here, and the status code
telling us the
condition of the actual response, now the next status code is the ones that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
condition of the actual response, now the next status code is the ones that
begin with the four,
this actually tells us that we have some type of client error, basically that
means that on our end
over here, the actual request that we sent was in valid or some problem with it
, so as we know,
the last two digits are going to tell us more about what that client error
actually is, so say for
example, if we get a four or one status code, this is a client error, and it
pretty much tells us is
that the server is rejecting a request because we actually do not have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that the server is rejecting a request because we actually do not have
authorization, so maybe you
forgot to put in your authorization header, maybe you put in the wrong
information within that header,
for whatever reason, the server is telling you you're not authorized, and it
really is telling you
that you look at the status code, four or one, you know straight away, hey I
better find out what
my authorization is, and then maybe give it a double check, and again if you
maybe make a request
and you get a four or four, this is telling you that the resource that you're
trying to get on the
server was not found, so maybe you should go and check the URL that you're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
server was not found, so maybe you should go and check the URL that you're
using because what you're
trying to request here is simply not found, sounds like you've got a problem,
so the next and final
category is the 500 status code, so again starts the five, this category here
is for when the server
itself happens to have an error, and again the next two digits tell you more
information if you happen
to see a 500 status code, this tells you that the server here happens to have
had some type of
internal server error, it's not used to client, the problem is very much over
here, whereas maybe WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here, whereas maybe
let's say you make a request to a server trying to do, let's go with a put
request to update some
information, and the actual API right here for whatever reason has not actually
implemented that type
of method, basically it does not support the updating of information via a put
request, then the
status code that you would see would be a 501 status code telling you that the
method that you're
using is not implemented, but it might actually be implemented later on down
the line in the future,
so as you can see these are some very important components of a rest API WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so as you can see these are some very important components of a rest API
utilizing our headers,
telling us a type of information we expect to receive the type of information
we're going to send,
as well as how we can authenticate with our server, and the server will always
give us back some
really insightful information about a request via our status codes, remember
the first digit will
tell you the class of response, and then the remaining two digits will tell you
the very specific
category of that class, so that you know exactly why the server responded the
way it did.