Narrator: Our next group is
the group of status codes beginning with four,
and these status codes represent client error.
So let's discuss some status codes belonging to this group.
So the first one is 400, bad requests.
What this status means is
that the client sent the server a bad request.
Now what makes a request a bad request?
There can be some reasons for this.
Parameters can't be validated.
For example, if the request contains an age parameter
and the number is negative
then of course this number is invalid
and in this case the server should return 400.
In addition, if the request contains a JSON structure
and this JSON is invalid and can't be parsed
then in this case also the server should return 400.
Now the 400 can be used with all the verbs.
It doesn't matter which verbs you are using.
Bad requests can occur with all of them
whether the problem is with the body
and in this case it's probably relevant more
for POST and put that have body into request.
But it can also be relevant for career string parameters
and in this case it will be more relevant for get.
Now, when returning 400 above request
consider using what is called RFC 7807 problem details.
This RFC is a standard that is being promoted
by the W3C
the top organization of the internet standards.
And this standard is
for returning a machine readable data about the problem.
Because let's think about it.
When the server returns 400
then the code that executed the request has nothing to do
with this response code.
All it knows is that there is some problem with the request
but the actual user, the end user
the human must examine the error and act accordingly.
Now, what the standard is trying to do
with the 7807 is trying to create a standard
for machine readable data about the problem.
So instead of returning a free text
that explains what the problem is
such as an edge cannot be negative
then the server will send a nicely formatted JSON
explaining the problem and giving a chance
to the client code to mitigate the problem.
So for example, this is how a response
from the server returning a 400
might look like when implementing this standard.
So you see that
in addition to the number
and the description and some headers
there is also a JSON format here containing data
about what the problem was.
So we have a field
of type which points to a schema explaining the problem.
There is a title, which is a free form text
and there is an invalid params
which contains the parameters
that were problematic with the request.
This is only part of the proposed schema.
And feel free to take a look at the link
at the bottom of the slide which contains the full Schema
of the proposed JSON.
So if your server returns 400, keep this standard in mind
and you will probably want to use it later.
The next status code
of the 400 group is the 401 unauthorized.
What this means is
that the client is not authorized to access the entity
and as a result, authorization is required.
Now this status should not be confused
with the 403, which is forbidden.
There is a difference
between the unauthorized and the forbidden.
And let's talk about the forbidden
and then we will understand the difference.
So the 403 forbidden means
that the client is not authorized to access the entity
but this status comes as a result of failed authorization.
So the user tried to get authorization to access
to the entity, but authorization was failed.
So to fully understand it, let's look at authorization flow.
So we have a client request
and the client goes to the server
and gets back 401 unauthorized.
Basically, the server tells the client
I don't know who you are, please authorize the client.
Then perform the authorization.
So it could be either with user and password
or active directory or multifactor authentication
any method of authentication supported
by the server is appropriate here.
And then after the authorization is made
the server might respond with the 403.
Now what this means in this case
that the server tells the user,
well now I know who you are
but you are forbidden from accessing this resource.
So again, notice difference
between the 401 and 403.
With 401, the server responds with
I don't know who you are,
with 403, the server responds with
I know who you are and you are forbidden.
And now let's go to the most famous response code,
which is as you probably guessed, the 404 page not found.
Now the 404 became so popular
that there are memes about it
and there are tailor made error pages
that make the 404 page not found funnier
and witty and actually quite nice to see
as you can see in this example.
So let discuss a little bit about 404.
So basically what it means is
the resource we were looking for is not found.
Now when are we going to use this status in API?
So we are going to use it
when a specific entity was looked for,
not with query parameters.
So if you remember the URL part we discussed
in the previous section
then there was a lecture
about the ID parameter
and the ID parameter
is the parameter that might cause a 404,
because when I'm looking for a specific entity
using the ID parameter
and this entity is not found
this is where I'm going to respond with 404.
In contrast, when a request is made with query parameters
and nothing is returned, this is not a good place
for the 404 because it is completely acceptable
for a query parameters request to not returning any entity
because maybe there is no entity that match the parameters.
The 404 status code can be used with all verbs
because with all the verbs
an entity can be specified in the request.
Now you might be thinking
that the 404 is not relevant for POST because
with POST we are creating a new entity
which naturally still have no ID
and therefore cannot be found.
But actually this is not the case because
if you remember when talking about the URL
we talked about sub entity
and you might be adding sub entity
to a specific entity using POST.
And then in this case
the URL of the POST
will still contain an ID of the entity itself
for which we want to add the sub entity.
Okay, so let's see a short demo on the 404.
So let's go back to our receptor.
And in this case I'm not going to create a new rule,
I just want to modify an existing one.
And let's click this icon near the POST API
we built in the previous lecture.
And I just want to modify the status
that instead of representing created, which is 201
I will switch it with 404 not found.
And that's it.
Let's save the rule.
Make sure that the mock status in the list displays 404.
And let's go to POSTman.
Now I don't need to change anything in POSTman.
It still displays the previous request
which was the exact same request I want to run now.
So I just hit the send button and look what we've got here.
The status now is 404 not found.
And if you will go to the console
you can see here at the bottom of the screen.
Let's open the new request
and the status is 404 not found.
So this is the meaning of 404
and you should use it when looking for a specific entity.