Now in the previous lectures,
I talked about handling errors that can occur.
And I talked about the 404 error,
which means that a resource is not found.
An error, typically cost by the client
requesting an invalid resource
and I talked about the 500 error,
which is a service site error.
Now these numbers are really just the status codes that we
typically use for communicating these kind of errors.
And I did talk about status codes before already.
I did say that that we typically have this 200 status code
as part of the response to signal that the request succeeded
and we are able to send back a valid response
and that'd be, for example, have 404 or 500 for the errors
I mentioned in the last lectures.
There also are other status codes, like 401, which is,
for example,
typically sent back if a user is not logged in and tries to
access a resource that requires logging in.
For example,
if you try to purchase a product on Amazon and you want to
go to the checkout page without being locked in,
that could be scenarios for that.
We'll see that status code 401 later.
There also are many other status codes.
Attached you find a link to all the available status codes
and we'll see some of them throughout this course,
the most common ones.
But there is one problem with those status codes.
It's nice that we have them
and it's nice that I named my files 404 EJS and 500 EJS.
With that, at least to us as a developer,
it's clear which template is used in which scenarios.
But if we have a look at the running application,
we actually don't see the status codes there.
If I enter an invalid, URL here.
If I try to access a restaurant that doesn't exist,
I get this 404 page
and that is all a typical user should see.
But technically we are not returning a totally clear or
correct response
and you can see that this is the case
if you open your developer tools and go to the network
tab there.
If I reload this page,
we see all the requests that were made
and if we click on the top most one,
which is the request to the HTML page itself,
I indeed get this kind of status code,
a 304, not modified.
Now here, we actually see a 304 status code instead of 200.
The only reason for that is that Chrome,
the browser I'm using here is actually caching old responses
for me,
which means it's basically saved these downloaded HTML files
or the HTML content locally on my computer to serve them
quicker for a subsequent requests,
and that's why I'm seeing a different status code here.
I could disable this by checking this disabled cash check
mark here in the network tab
and then I would see the 200 response.
Since I haven't disabled this here,
If I reload this, I get the 304 response.
But 300 dish status codes,
so status codes in the 300 hundred area,
as well as 200 dish status codes
mean that the request was successful
and you did get the response that you requested in the end.
And that's the wrong message here,
because this is not the response we requested.
We want the details for the restaurant, with this ID.
And what we got is a page that tells us that this restaurant
doesn't exist. That's not a success, that's a failure.
And therefore we should also communicate that with the
status code, by setting a errors status code here,
even though that won't affect, what's visible on the page.
That's important, that won't change.
The page content will always be what you see here,
but still we want to communicate the correct status code,
the technically correct status code
to the browser so that the browser, for example,
does not save cache this error page locally,
but that the browser knows that for this request,
so for a get request to this URL,
we did not get a success response.
We want to make that clear and at the moment we aren't.
And to be technically correct,
you can dare for all the call and never method on this
response object here before you call render.
And that's the status method.
Now what I'm doing here is called chaining.
I'm calling a method after calling another method.
So I'm calling this render method on the result of calling
status and status simply returns us
an updated response object.
So I'm technically still calling render on my
response object, but on a slightly updated one.
And what did change well,
status allows me to set a custom status code
and the default would be 200.
Here, I do want to set it to 404
and hence me simply pass 404 as a
number to status.
And here, when we render 500, I will set this to status 500.
And in the other place where we have a 404 error,
Here,
when we don't find a restaurant with that ID,
I also call status first and set this to 404.
Now, if we save all of that
and we opened the developer tools again,
if I reload this page now,
you'll see the request is a red,
and now we have data appropriate status code here.
Now to the user who doesn't use these developer tools,
nothing changes on the screen.
Still, this is technically more correct
and it can have an impact, for example,
on some optimizations, the browser might perform.
That's why we should be correct technically
even if the user doesn't directly see
that changed status code.
Now over the next lectures,
you won't see that code anymore because I added this after
recording the next lectures,
because originally I planned on showing this later,
but plans changed
and this is important to understand right now,
because this now is a technically valid 404 response with
our 404 page content and the appropriate status code to
clearly communicate to the client,
to the browser, that this is a response,
but not the expected one.