So right now we're checking this thing over here.
Request dot readystate is equal to four, and at that point, the request is complete.
And then we're logging the response text to the console, and that's fine.
But this check in itself to say, okay, well, the request is complete, that's not enough.
Because if there was some kind of error with the request, for example, if I create some kind of end
point which is not valid, it still tries to make this request and it still goes through the motions
of going through each phase or state and it will reach state four.
But the difference is we're not going to get any kind of data back because this is not correct.
There will be some kind of error along the line.
And although it will reach stage four to say yet the request is now complete, it will come back with
some kind of error code to say there was a problem along the line somewhere and obviously we won't have
access to the response.
So let me just demo this.
I'm going to just log out the request object in itself here, as well as the response text.
And I've added this extra s to the URL, the end point.
So obviously this doesn't exist and we should see some kind of error, but I'm going to log out the
request anyway and try to log out the response text.
So let me save this and come over here.
And now we can see, first of all, we get this 404 error and we get this thing right here.
This is the request object.
Notice we don't see any response text when we're logging this we don't see over here because we're not
getting that data anymore because there's an error.
Now, if we open this up and we come down here, we can see the status right here is 404 and the response
text is empty.
So we still reaching ready state four and we're still firing this code.
That's not a problem.
We're still getting there.
It's just that there's been an error along the way and now we're getting this bad status 404 and also
no response text.
So what we need to do to overcome this is as well as checking the ready state.
Also check the status when the request comes back.
So if I correct this again to the correct endpoint and save it, notice now we get the data and also
up here we can see this object.
If we expand that, we get a status of 200.
We're at ready State four, we get the response text and we have a status of 200.
Now a status of 200 means that everything was okay with the request and it's come back with the data
essentially.
Now, the 404 request that we just saw means it cannot find the resource that we're trying to send it
to and it can't find it because it didn't exist when we added this s on that resource, this endpoint,
it didn't exist.
So that's why we get a 404 error.
Sometimes when you go to a web address up here that doesn't exist, you'll probably see some kind of
404 error in your browser.
That's the same kind of error.
Now there's loads of different types of status codes and you can get them all from a lot of different
websites.
This one, the Mozilla Guide lists every single one as well.
So typically we get codes in the ranges of the 100, 200, 300, 405 hundreds.
And in each range it means something a bit different.
So all of the status codes in the 100 range, they are to do with information, responses, anything
to do with success responses is in the 200 range.
We can see 200 right here is okay.
And then the 300 range is any kind of redirection messages.
The 400 range is client error responses.
So this is when there's an error in the browser, such as when we formatted something incorrectly in
the code or if we use a wrong endpoint.
ET cetera.
This is the one we saw 404 not found.
And then 500 is when there's a server error over here.
So it's not our fault we've made the correct type of request, but there's some kind of error on the
server which prevents us from getting the data.
So there are different kinds of response codes.
What we want to do is to make sure that we have this response status.
So as well as checking for ready state for over here, we can also check for the status right here to
be 200.
So we've seen how to do logical and double ampersand and we say request dot status is equal to 200.
Now this is only going to fire when we get an okay response and ready state equal to four.
So let me try this again.
I'm going to save it.
And notice now we don't log out this thing right here, the request object, because this now is not
firing, because the status is not 200.
We still get this error up here to say we got a 404 error, but we're not trying to do something now
over here.
We're only doing this when we have a correct endpoint.
So if we save it now, we can see all of this stuff here on the object.
So what we could.
Do is attack on an else clause.
And in fact, we'll say else if and then in this if statement, we're still going to check this thing
over here like so now, if this is the case, if the ready state is still equal to four, but obviously
at this point, the status is not 200.
So something's maybe not okay, then we can fire this code block over here.
So the request is finished.
But there's been some kind of problem along the way and we probably don't have any kind of response
text.
So what we could do here is say console dot log could not fetch the data.
Okay?
So if we save that now and try something like adding an S on, save it and we can see now we get this
little error message in the console could not fetch the data.
So now we have our Http request set up.
The next step is to write a callback function which is going to execute when this task is complete.
And we'll tie this back into our understanding of asynchronous code.
