1 00:00:00,172 --> 00:00:02,280 Narrator: Our next group is 2 00:00:02,280 --> 00:00:05,370 the group of status codes beginning with four, 3 00:00:05,370 --> 00:00:09,000 and these status codes represent client error. 4 00:00:09,000 --> 00:00:13,230 So let's discuss some status codes belonging to this group. 5 00:00:13,230 --> 00:00:16,650 So the first one is 400, bad requests. 6 00:00:16,650 --> 00:00:18,060 What this status means is 7 00:00:18,060 --> 00:00:22,440 that the client sent the server a bad request. 8 00:00:22,440 --> 00:00:25,500 Now what makes a request a bad request? 9 00:00:25,500 --> 00:00:28,470 There can be some reasons for this. 10 00:00:28,470 --> 00:00:30,600 Parameters can't be validated. 11 00:00:30,600 --> 00:00:34,290 For example, if the request contains an age parameter 12 00:00:34,290 --> 00:00:36,360 and the number is negative 13 00:00:36,360 --> 00:00:39,270 then of course this number is invalid 14 00:00:39,270 --> 00:00:43,061 and in this case the server should return 400. 15 00:00:43,061 --> 00:00:47,490 In addition, if the request contains a JSON structure 16 00:00:47,490 --> 00:00:50,370 and this JSON is invalid and can't be parsed 17 00:00:50,370 --> 00:00:55,200 then in this case also the server should return 400. 18 00:00:55,200 --> 00:00:58,350 Now the 400 can be used with all the verbs. 19 00:00:58,350 --> 00:01:01,260 It doesn't matter which verbs you are using. 20 00:01:01,260 --> 00:01:03,600 Bad requests can occur with all of them 21 00:01:03,600 --> 00:01:06,450 whether the problem is with the body 22 00:01:06,450 --> 00:01:08,970 and in this case it's probably relevant more 23 00:01:08,970 --> 00:01:13,050 for POST and put that have body into request. 24 00:01:13,050 --> 00:01:16,980 But it can also be relevant for career string parameters 25 00:01:16,980 --> 00:01:21,060 and in this case it will be more relevant for get. 26 00:01:21,060 --> 00:01:24,450 Now, when returning 400 above request 27 00:01:24,450 --> 00:01:29,450 consider using what is called RFC 7807 problem details. 28 00:01:30,720 --> 00:01:34,320 This RFC is a standard that is being promoted 29 00:01:34,320 --> 00:01:36,300 by the W3C 30 00:01:36,300 --> 00:01:38,820 the top organization of the internet standards. 31 00:01:38,820 --> 00:01:40,290 And this standard is 32 00:01:40,290 --> 00:01:44,340 for returning a machine readable data about the problem. 33 00:01:44,340 --> 00:01:45,810 Because let's think about it. 34 00:01:45,810 --> 00:01:48,390 When the server returns 400 35 00:01:48,390 --> 00:01:52,470 then the code that executed the request has nothing to do 36 00:01:52,470 --> 00:01:54,150 with this response code. 37 00:01:54,150 --> 00:01:57,660 All it knows is that there is some problem with the request 38 00:01:57,660 --> 00:02:00,750 but the actual user, the end user 39 00:02:00,750 --> 00:02:05,610 the human must examine the error and act accordingly. 40 00:02:05,610 --> 00:02:07,588 Now, what the standard is trying to do 41 00:02:07,588 --> 00:02:10,637 with the 7807 is trying to create a standard 42 00:02:10,637 --> 00:02:14,970 for machine readable data about the problem. 43 00:02:14,970 --> 00:02:17,460 So instead of returning a free text 44 00:02:17,460 --> 00:02:19,260 that explains what the problem is 45 00:02:19,260 --> 00:02:21,930 such as an edge cannot be negative 46 00:02:21,930 --> 00:02:25,000 then the server will send a nicely formatted JSON 47 00:02:25,000 --> 00:02:29,280 explaining the problem and giving a chance 48 00:02:29,280 --> 00:02:32,190 to the client code to mitigate the problem. 49 00:02:32,190 --> 00:02:35,250 So for example, this is how a response 50 00:02:35,250 --> 00:02:37,349 from the server returning a 400 51 00:02:37,349 --> 00:02:40,140 might look like when implementing this standard. 52 00:02:40,140 --> 00:02:41,310 So you see that 53 00:02:41,310 --> 00:02:43,380 in addition to the number 54 00:02:43,380 --> 00:02:45,261 and the description and some headers 55 00:02:45,261 --> 00:02:50,261 there is also a JSON format here containing data 56 00:02:50,640 --> 00:02:52,680 about what the problem was. 57 00:02:52,680 --> 00:02:53,850 So we have a field 58 00:02:53,850 --> 00:02:58,850 of type which points to a schema explaining the problem. 59 00:02:59,220 --> 00:03:01,860 There is a title, which is a free form text 60 00:03:01,860 --> 00:03:04,530 and there is an invalid params 61 00:03:04,530 --> 00:03:06,870 which contains the parameters 62 00:03:06,870 --> 00:03:09,390 that were problematic with the request. 63 00:03:09,390 --> 00:03:12,330 This is only part of the proposed schema. 64 00:03:12,330 --> 00:03:15,090 And feel free to take a look at the link 65 00:03:15,090 --> 00:03:18,330 at the bottom of the slide which contains the full Schema 66 00:03:18,330 --> 00:03:20,130 of the proposed JSON. 67 00:03:20,130 --> 00:03:24,210 So if your server returns 400, keep this standard in mind 68 00:03:24,210 --> 00:03:26,643 and you will probably want to use it later. 69 00:03:27,660 --> 00:03:28,860 The next status code 70 00:03:28,860 --> 00:03:33,480 of the 400 group is the 401 unauthorized. 71 00:03:33,480 --> 00:03:34,710 What this means is 72 00:03:34,710 --> 00:03:39,300 that the client is not authorized to access the entity 73 00:03:39,300 --> 00:03:43,470 and as a result, authorization is required. 74 00:03:43,470 --> 00:03:46,376 Now this status should not be confused 75 00:03:46,376 --> 00:03:50,790 with the 403, which is forbidden. 76 00:03:50,790 --> 00:03:51,990 There is a difference 77 00:03:51,990 --> 00:03:55,140 between the unauthorized and the forbidden. 78 00:03:55,140 --> 00:03:57,150 And let's talk about the forbidden 79 00:03:57,150 --> 00:04:00,000 and then we will understand the difference. 80 00:04:00,000 --> 00:04:04,170 So the 403 forbidden means 81 00:04:04,170 --> 00:04:08,580 that the client is not authorized to access the entity 82 00:04:08,580 --> 00:04:13,580 but this status comes as a result of failed authorization. 83 00:04:13,710 --> 00:04:17,130 So the user tried to get authorization to access 84 00:04:17,130 --> 00:04:20,673 to the entity, but authorization was failed. 85 00:04:21,779 --> 00:04:25,773 So to fully understand it, let's look at authorization flow. 86 00:04:26,640 --> 00:04:29,220 So we have a client request 87 00:04:29,220 --> 00:04:31,650 and the client goes to the server 88 00:04:31,650 --> 00:04:35,940 and gets back 401 unauthorized. 89 00:04:35,940 --> 00:04:39,000 Basically, the server tells the client 90 00:04:39,000 --> 00:04:43,620 I don't know who you are, please authorize the client. 91 00:04:43,620 --> 00:04:45,720 Then perform the authorization. 92 00:04:45,720 --> 00:04:48,660 So it could be either with user and password 93 00:04:48,660 --> 00:04:52,110 or active directory or multifactor authentication 94 00:04:52,110 --> 00:04:54,030 any method of authentication supported 95 00:04:54,030 --> 00:04:55,890 by the server is appropriate here. 96 00:04:55,890 --> 00:04:58,380 And then after the authorization is made 97 00:04:58,380 --> 00:05:02,460 the server might respond with the 403. 98 00:05:02,460 --> 00:05:04,290 Now what this means in this case 99 00:05:04,290 --> 00:05:07,050 that the server tells the user, 100 00:05:07,050 --> 00:05:09,300 well now I know who you are 101 00:05:09,300 --> 00:05:13,260 but you are forbidden from accessing this resource. 102 00:05:13,260 --> 00:05:14,790 So again, notice difference 103 00:05:14,790 --> 00:05:18,090 between the 401 and 403. 104 00:05:18,090 --> 00:05:20,736 With 401, the server responds with 105 00:05:20,736 --> 00:05:22,980 I don't know who you are, 106 00:05:22,980 --> 00:05:26,160 with 403, the server responds with 107 00:05:26,160 --> 00:05:29,370 I know who you are and you are forbidden. 108 00:05:29,370 --> 00:05:34,020 And now let's go to the most famous response code, 109 00:05:34,020 --> 00:05:39,020 which is as you probably guessed, the 404 page not found. 110 00:05:39,510 --> 00:05:42,360 Now the 404 became so popular 111 00:05:42,360 --> 00:05:44,580 that there are memes about it 112 00:05:44,580 --> 00:05:47,310 and there are tailor made error pages 113 00:05:47,310 --> 00:05:50,910 that make the 404 page not found funnier 114 00:05:50,910 --> 00:05:53,221 and witty and actually quite nice to see 115 00:05:53,221 --> 00:05:56,070 as you can see in this example. 116 00:05:56,070 --> 00:05:59,610 So let discuss a little bit about 404. 117 00:05:59,610 --> 00:06:01,441 So basically what it means is 118 00:06:01,441 --> 00:06:05,820 the resource we were looking for is not found. 119 00:06:05,820 --> 00:06:09,390 Now when are we going to use this status in API? 120 00:06:09,390 --> 00:06:10,770 So we are going to use it 121 00:06:10,770 --> 00:06:13,800 when a specific entity was looked for, 122 00:06:13,800 --> 00:06:16,290 not with query parameters. 123 00:06:16,290 --> 00:06:19,560 So if you remember the URL part we discussed 124 00:06:19,560 --> 00:06:21,030 in the previous section 125 00:06:21,030 --> 00:06:23,040 then there was a lecture 126 00:06:23,040 --> 00:06:24,570 about the ID parameter 127 00:06:24,570 --> 00:06:26,280 and the ID parameter 128 00:06:26,280 --> 00:06:30,090 is the parameter that might cause a 404, 129 00:06:30,090 --> 00:06:32,970 because when I'm looking for a specific entity 130 00:06:32,970 --> 00:06:34,620 using the ID parameter 131 00:06:34,620 --> 00:06:36,540 and this entity is not found 132 00:06:36,540 --> 00:06:39,277 this is where I'm going to respond with 404. 133 00:06:40,140 --> 00:06:44,760 In contrast, when a request is made with query parameters 134 00:06:44,760 --> 00:06:48,030 and nothing is returned, this is not a good place 135 00:06:48,030 --> 00:06:50,873 for the 404 because it is completely acceptable 136 00:06:50,873 --> 00:06:55,620 for a query parameters request to not returning any entity 137 00:06:55,620 --> 00:06:59,816 because maybe there is no entity that match the parameters. 138 00:06:59,816 --> 00:07:02,910 The 404 status code can be used with all verbs 139 00:07:02,910 --> 00:07:04,920 because with all the verbs 140 00:07:04,920 --> 00:07:08,040 an entity can be specified in the request. 141 00:07:08,040 --> 00:07:09,360 Now you might be thinking 142 00:07:09,360 --> 00:07:12,540 that the 404 is not relevant for POST because 143 00:07:12,540 --> 00:07:15,300 with POST we are creating a new entity 144 00:07:15,300 --> 00:07:18,180 which naturally still have no ID 145 00:07:18,180 --> 00:07:20,640 and therefore cannot be found. 146 00:07:20,640 --> 00:07:22,920 But actually this is not the case because 147 00:07:22,920 --> 00:07:25,260 if you remember when talking about the URL 148 00:07:25,260 --> 00:07:27,600 we talked about sub entity 149 00:07:27,600 --> 00:07:30,600 and you might be adding sub entity 150 00:07:30,600 --> 00:07:33,300 to a specific entity using POST. 151 00:07:33,300 --> 00:07:34,470 And then in this case 152 00:07:34,470 --> 00:07:36,002 the URL of the POST 153 00:07:36,002 --> 00:07:40,770 will still contain an ID of the entity itself 154 00:07:40,770 --> 00:07:43,323 for which we want to add the sub entity. 155 00:07:45,000 --> 00:07:48,457 Okay, so let's see a short demo on the 404. 156 00:07:50,910 --> 00:07:54,060 So let's go back to our receptor. 157 00:07:54,060 --> 00:07:57,030 And in this case I'm not going to create a new rule, 158 00:07:57,030 --> 00:07:59,940 I just want to modify an existing one. 159 00:07:59,940 --> 00:08:04,940 And let's click this icon near the POST API 160 00:08:05,130 --> 00:08:07,743 we built in the previous lecture. 161 00:08:08,580 --> 00:08:11,670 And I just want to modify the status 162 00:08:11,670 --> 00:08:16,670 that instead of representing created, which is 201 163 00:08:16,710 --> 00:08:20,760 I will switch it with 404 not found. 164 00:08:20,760 --> 00:08:21,990 And that's it. 165 00:08:21,990 --> 00:08:22,920 Let's save the rule. 166 00:08:22,920 --> 00:08:27,420 Make sure that the mock status in the list displays 404. 167 00:08:27,420 --> 00:08:29,193 And let's go to POSTman. 168 00:08:32,220 --> 00:08:35,309 Now I don't need to change anything in POSTman. 169 00:08:35,309 --> 00:08:38,130 It still displays the previous request 170 00:08:38,130 --> 00:08:41,669 which was the exact same request I want to run now. 171 00:08:41,669 --> 00:08:46,670 So I just hit the send button and look what we've got here. 172 00:08:48,270 --> 00:08:52,020 The status now is 404 not found. 173 00:08:52,020 --> 00:08:55,020 And if you will go to the console 174 00:08:55,020 --> 00:08:58,500 you can see here at the bottom of the screen. 175 00:08:58,500 --> 00:09:00,750 Let's open the new request 176 00:09:00,750 --> 00:09:04,170 and the status is 404 not found. 177 00:09:04,170 --> 00:09:07,170 So this is the meaning of 404 178 00:09:07,170 --> 00:09:11,373 and you should use it when looking for a specific entity.