REST API Response Explained | Status Codes & Response Body | System Design | 8

Hinzugefügt: 2026-05-07

[00:00:01][music] >> So now, once we have understood the request correctly, it is time to understand the responses. So in order to understand the response, first we need to understand the response code. So there are specific codes assigned to a specific type of response, which if the user gives, we will clearly understand what they want to tell us. So, let me start with those status codes, and then we will move forward. So these are all the response codes which we have to know. 200 stands for okay. So this means everything is working as expected. Don't worry about it. Then we have 201. 201 is basically used when there is a new entity created in the database. So this is created. Then we have 204. 204 is again saying that everything is working fine, but I don't have anything to provide to you. Let's say we are deleting any entity, so it is successfully deleted, but they don't have any response body to give to us. So that means there is no content to give to us, but the request is working fine.

[00:01:03]Then we have 301. 301 is basically used for redirects, and 301 indicates that it is a permanent redirect. And if the redirect is not permanent, then we use 302. That is temporary redirect. Then we will come to the 400 series. So all the 400 series basically says that there is some issue with the request we are having. So the 400 stands for bad request. That means some or the other data is not correctly mentioned in the body. Either they have some validation issue, either either they are missing when they are required, either they have some other issues. But request which we are getting, the body doesn't have the correct information. So in that case, we normally give 400 bad request as a response. Then we have is basically used when there is a new entity created in the database. So this is created. For which they are not basically authorized.

[00:02:02]So 401 is unauthorized. With that we have 403, which is used for forbidden.

[00:02:10]Suppose on an LMS you have not enrolled for a course and you want to access a particular video or lesson part of that course, which is not publicly accessible. So in that case, you will receive 403 forbidden, because you are not allowed to see that particular resource. With this, we have 404, page not found. This is basically used when a the URL is incorrect or trying to access some or the other resource which is not there into our system. And at last, we have 500. So 500 is the response which is given to a front-end when there is something wrong with the back-end. So this is related to back-end. Some or the other error is there in the back-end.

[00:02:51]Maybe some syntax error, maybe some other error, some logic is missing, some data is missing, something is wrong with back-end. So this is internal server error. There are many errors which we don't want users to see. So those all are handled by 500, because we don't want the user to understand what is the issue we are facing with our database connection or anything. So we will create logs into our system, and through which we'll resolve the 500 error issues. So these are all the most commonly used response codes which we have to understand. So now, whenever we are creating any APIs, if the response is completely fine, we will provide 200.

[00:03:32]If we are creating any entity, we will provide 201. If we are deleting or performing some operations where we don't have to give any content or any data or any body in the response, we will use 204. Then if the permanent redirection is there, we will use 301.

[00:03:50]If the redirection is for temporary basis, we will use 302. For any bad request in the body, we will use 400.

[00:03:59]For authorization, we will use 401.

[00:04:02]For forbidden or the content which requires some special access, we will give 403. 404 we will give when they are trying to access any resource which is not there. And 500 we will give when there is any issue in the internal server. So with this, let's move to the next part, which is response body. So normally in response body, what is allowed first we start with that. So we can return an array, right? Also, we can return an object. With this, also we can return data as nested objects. Now, in most of the applications, whenever you are going through any YouTube tutorial or any course also sometimes, when you are dealing with multiple responses, let's say the responses for this is normally an array, right? But it is not recommended to handle the response as array. It should always be wrapped in the form of an object. And if you want, you can use any other key for this users. And in the value, you will give these responses. Now these can also be string or an object. Normally an object only of all the users, but it should be handled like this. So this is the correct, or I would say recommended way. So every response body should be an object. And even if we are trying to give an array, we have to wrap it up into an object and give us in the key-value form. So this is a good practice, and through this we will achieve a more long-lasting code.

[00:05:37]Why? Let's say today we are passing the user details only, and tomorrow we understand that okay, we have to add more fields. So we don't have to change much on the front-end side or the receiving side, but we will simply update our response, change the object here, and maybe add some other field, user count, and pass that information, maybe 29. And with this, we can end our object here. So we can pass as many informations as we want. But if we have used a single array as a response, then we have to struggle with it, and we have to change the entire architecture of our response. So it is always recommended to pass the response always in the form of an object. So let me write, "Returning as array, not recommended." Let me know in the comments if you already knew about this or you are hearing this for the first time. So with this, let me create a map of request type and responses. So let's say here we have request. Here are the responses which we are going to receive. So if the request type is get, and we are trying to access many records, so maybe we are trying to access users. It is going to give an array of records, right? So it is normally going to give 200 as a response code, and going to give an array. Now we understand that we have to not give array directly. So it will be wrapped in the form of an object. Now the next request is also a get request, where we want to access a particular object.

[00:07:16]Let's say one. Now you can think that we will give the user information directly, but again, it is not recommended to give that directly. We will use the nested object for the same reason. So in this object, we will use the user as key, and pass on the user information into this object. So this is the actual user object, but we are wrapping it into an another object because it will give us flexibility to pass some more information if we want to. So, let me clear this up for now. So normally, we are going to get 200 response with this kind of nested objects. Also, it is possible that this ID is not there in our DB. In that case, we can also give 404 response. Now if we are adding anything, we will use post with the same URL. And normally, it is going to give 201 response, which means the entity is created. And also, we can use 200 response if you want. But if we are using 201, normally we give the ID or the new object as response. Now here, with post request, we are also giving the body, so it can also have 400 issues, right? 400 bad request issue.

[00:08:35]And also, if the format doesn't sync in, it can also give 500 issue. If the data is coming properly and there is some issue in the back-end, it can also give 500 easily. So these are most common response codes which you can have while working with post. Now let's talk about delete. In delete, also we will pass this URL with some ID. And this can also give 200 as a response. And also, if it is deleted correctly and we don't want to give any body in the response, we can go for 204. If this entity is not present, maybe the ID they are using is one and we don't have any record with the ID one, we can have 404. Or we can have 500 if there are any dependencies, and which is not handled correctly by our back-end. With this, you can also see 401 here if you are unauthorized person to delete that particular record, or you are not allowed to delete that particular entity, you can also get 401.

[00:09:37]So these are the most common request responses, and with that we have also discussed what can be there in the response body. So with this, we have covered the entire request section and the response part of the REST APIs. And I hope the information which you get from this video is going to help you in your entire development career, whenever you are dealing with REST APIs.