We started writing this "login" API route,
that accepts a POST request.
And we've seen how we can read the data
sent in the request body.
Instead of logging that data,
let's extract the "email" and "password" properties
from the "req.body".
And what we want to do at this point is
send these credentials to the CMS API.
This means we need to do
pretty much the same thing we already did
in the SignInPage.
So let's copy this code from here
and paste it into our handleLogin function.
We'll need to import "fetchJson".
And also make this function "async",
because we're using "await"
to unpack the Promise returned by "fetchJson".
Now, what do we do with this response?
Let's start by logging it.
So this is the "CMS response".
Let's try calling our API route now.
We still get "200 OK"
with an empty JSON object in the response.
But if we look at the logs
we can tell that it did call the CMS,
and it received a response
containing the JSON web token and the user details.
So we could use that data to return
something more useful in our own response.
We know that the CMS response will contain
the "jwt" string and a "user" object.
No need to log this any more.
Rather, we want to return something
in our JSON response.
Now, we don't want to put the token here,
because we said we should set that as a cookie,
and we'll see how to do that later.
But we could return some user details.
And we could select only
the properties we actually need,
instead of passing the entire "user" object.
So we could pass the "id",
that is the "user.id",
and maybe the name of the user,
in case we want to display that on the UI.
In the CMS response
this is called the "username".
But we can rename properties as we see fit
in our own response.
Now, let's try sending another request.
This time it doesn't log anything,
but the response body
contains the user details we're interested in,
that is "id" and "name".
And their values are those coming from the CMS.
Ok. So far so good.
Now, what happens if we send the wrong password?
In this case we get a "500 Internal Server Error",
and if we check the logs
that's because "fetchJson" throws an ApiError,
which is the custom error we defined,
so that's expected.
But we need to handle this scenario
in our API handler,
by catching any errors.
And in this case we could return
a more appropriate HTTP status code,
like 401 that stands for "Unauthorized".
Because it's not a "Server Error"
if the user entered the wrong password.
Again, keep in mind that I'm treating all errors
in the same way here, just to keep things simple.
But it would be better to handle
network errors for example in a different way.
Anyway, if we go and test our login request again,
this time we get a "401 Unauthorized" response.
So this is what will tell the client
that the credentials were invalid.
Now, what we're still missing here is
what was our original reason for
writing this API route in the first place,
that is setting a cookie
containing the JSON web token.
And we'll take care of that in the next video.