Hey did everyone that they share.
And welcome to another video of the pro back end developer course.
Now our application is looking good and it's fine and we can definitely move forward in building the
application.
But of course the goal is not to build that toy application.
The goal is to understand the in depth of what we're trying to achieve here.
Now, two new keywords are right in front of us, the first one being request and the second one being
response.
In fact, many of the time you are going to see that there is something like a next or there is a whole
lot of things that goes on.
But right now the goal is really simple that I want to understand more in-depth about request and the
response.
Now, the request is something which we have already seen.
This can be a type of get post put and delete and a little bit more, but this is all the requests that
you are trying to make to the server.
And not only just you can take some things like that, you have type to search on, you can take a lot
of information to the server at the time of requesting it.
Similarly, server can respond and server response you in the form of response, also known as this
rest.
And this is how we are sending back this data.
But we need a little bit more in-depth analysis of that.
And this analysis and this study is going to depend on what kind of framework you are choosing on.
We are choosing EXPRESS.
So we're going to study the Express documentation in case you choose something else.
Obviously have to study different, but after this course, okay, let's move on.
So this is the basics and let's go up here.
So first, let's talk about how this is happening.
So Web request in response, we have already gone through that request.
Is there as soon as you make a request on the Web, the Web starts analyzing that request process,
that request, maybe grab some data from the database and then finally it gets you a response back.
But not only just response, it also sometimes gets you a status or also known as status code.
This is really important.
This is the information that is important to write better APIs or as well as formal APIs or the production
grade APIs.
Let's go ahead and obviously I have a link for you to explore on these Web requests.
So let's go ahead and open this up.
So this is the HTTP response status code.
You don't need to memorize any of it.
There are only a handful of few which we use, but if you know a lot more, that is always great.
So for all the information, informational response we use between 100 to 199, I'll explain more in
detail what those are for successful response 202 to 99.
This is usually the range you are going to be mostly using 200 or 201.
Then there is a redirection message.
You won't be using too much of the 300 codes 405 hundred code.
You'll be using 400 code for when a client gives you something wrong.
Information for something like a wrong email or something like this or the password doesn't match.
We use a range of 400 code and then 500 code.
Now the good thing is these codes are not kind of governance bodies.
You can decide that whatever the code you want to return, of course you can return for all successful
message 200 code, but nobody is stopping you to return a 400 code.
Of course it would be bad for the API design, but nobody's stopping you to do so.
I am stopping you.
Please don't do this.
This is really bad.
A couple of ones which I would like to introduce.
You don't need to remember all of them for all the get head put, body trace, all kinds of this you'll
be mostly using 200.
200 means everything is okay.
It was successful.
Now it is recommended that for all the post input request you send at 201, whenever there is a new
record being created in the database, you'll find that majority of the Pro-level organization use this
specific code, so make sure you remember that.
But in the majority of the applications and videos and courses, we actually tend to use 200 more.
And this is all okay.
This is not bad at all.
Now in the 300 you won't be using too much of the redirections of the code.
Something like 300 not found in all of that.
So these are rarely used, but most of the time you'll be using 400.
These are for client requests, like bad request.
Or maybe somebody is trying to access a resource which is not authorized for him.
The payment for or to nobody.
I've seen ever you using this one so I don't know.
It might be used somewhere.
403 is almost similar to 401, but this is forbidden for every one resource and stuff like that.
500 is definitely when something goes wrong onto the server.
So you're going to see scrolling a little bit something like Bad Gateway.
You might have seen this many times and internal server error, of course, a famous one now one of
the common one is 4 to 4.
I'm pretty sure that most of you might be familiar with the 404 not found.
When you don't find the resource on the server again, you don't need to memorize all of them.
Just remember that 200 and 201 are okay.
Responses 404 is not found.
400 is just basically there is something wrong from the client side.
So something like bad request or something.
And 401 is unauthorized 500 is something went wrong from our site on the server.
These are the basic ones that you have to remember.
So this is the basics now coming back onto the express.
Now this time we'll be going a little bit more than the getting started.
This guide.
We need to understand how the APIs of Express works.
Yes, they have their own APIs as well.
So let's.
Go on to the five X because that's what we are using.
And again, in case you want to get more detail which one you should be looking for, you can go ahead
and look for that.
We are using a 4.71.
So of course the version five is not yet being released.
So you might be looking for the four x, not the five x.
So let's go ahead and look for four X in case you want to check out the five x, this is exactly how
you would be doing.
So here we can see we have a request and we have a response.
First, let's see what all we can do in the request.
So you can see there is a whole lot of things that can come up in the request.
You can access the body, you can access the base URL, you can access cookies, you can access host
name.
There's a whole lot that we can do here.
There is a path, there is params.
I will explain them in more detail.
There is a query route, signed cookies.
There's a whole lot that comes up with the request.
And of course, I know many of you didn't realize this, but yes, cookies and parameters and token,
even when you reset your password or you access the email first time and you create an account and say,
hey, I'm authorized, this is all been coming up in the token from the URL itself and this all comes
from the request.
So this is it.
And when it comes to the response, this is where the response comes in or response from the server
side is being sent to anybody who is requesting it.
So you can send headers and this is the most common one and you can also go ahead and use something
like resource send that we just use, which is somewhere here.
There we go, restart, send and this is what we have been using, resort send and we send up some paragraph
or something like that.
So this is where it is coming up.
You can also send raised or JSON and we can send the JSON data which we'll be sending up in a minute
and all of that.
But there is an important one which you are going to see.
There is a red dot send status and resource status.
So I told you status is for raising something like four or three, 400, whatever the status is, but
very similar of that which is red dot send status.
So what's the difference between the resort status and resort send status?
Not too much resident status send status.
Actually, you not only just send the status, you actually bind it up with a little bit more.
Like you can see that as dot status.
When you want to simply say send status, that means I only want to send the status, just the code
400 300 201, whatever.
But when I use something like resident status, then I can just use the status to send the status,
but I can also chain on this dot send to send whatever the request is that I'm sending you.
And again, all you have to do is come up here and read that.
For example, if you want to set some cookies, you have to say it as dot cookie and stuff like that.
So that's all what we do.
Now, let's go ahead and modify our request that we have sent to make it a little bit more professional.
Not too much, but a little bit.
So I can simply say resident status and this time we are sending up an okay request.
So 200, everything is okay and then I can chain on a dot send and everything like that.
If I save this you can see server is still up and running and our browser is not going to make any difference.
And that's where the postman comes in.
This is exactly the time where you see that what request comes up.
So let me go ahead and fire up my postman.
And there we go.
It's going to take a little bit of the time.
There we go.
And come on, you can do this.
And I'm going to just open up a new.
Just open up.
Just close all of these guys and just open up a new tab.
And it will open up a new request for you.
You might be up here somewhere and just click on this plus icon and you'll be getting that.
Let's go ahead and use the local host for 1000 and a slash.
And of course, you can choose all of your get posts.
There is a whole lot that it allows you, but we'll be just going for the get as soon as I send this
the notice here it says here, start us 200 OC and it says a response of Hello World.
Now let's go ahead and try to change this response to just see that RV on the same page or not.
If I go ahead and say 201, which is not really an ideal status code in this case, but if I try to
go ahead and send this now, I say to a one created now nothing has been created, but I told you,
nobody's stopping you to do so.
But this is where the status code is responsible and where it is being used at the time.
When somebody is working on the front end, they will be proceeding further based on the status code.
If the status code is 400, there's no point of moving further because something is wrong.
If the status code is 200, that means everything is okay and I can proceed further off however I have
planned on.
So status code are really important and it is recommended that if you're creating a pro grade or production
grade application, you should always put the status code.
That's it for this video.
Let's catch up in the next one.