WEBVTT 1 00:00.000 --> 00:03.840 Alright friends, let's talk about headers within our REST APIs. 2 00:03.840 --> 00:07.680 So the first header that I want to talk to you about is one called an accept 3 00:07.680 --> 00:08.320 header. 4 00:08.320 --> 00:12.790 So let's just quickly draw out the scenario over here we have our clients, okay 5 00:12.790 --> 00:12.800 ? 6 00:12.800 --> 00:16.240 And over here what we can do is have our server. 7 00:16.240 --> 00:20.880 So the client is going to make a request to the actual server here as it does. 8 00:20.880 --> 00:25.280 And as we know it's going to be using HTTP or preferably HTTPS. 9 00:25.280 --> 00:28.240 Now in this request if we specify an accept header, 10 00:28.240 --> 00:33.690 what we can do is specify the value and tell the server the type of data that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:28.240 --> 00:33.690 what we can do is specify the value and tell the server the type of data that 11 00:33.690 --> 00:35.040 we are willing to accept 12 00:35.040 --> 00:38.720 as a client. So let's just say this server happens to have a whole bunch of 13 00:38.720 --> 00:40.080 information about, 14 00:40.080 --> 00:44.080 oh I don't know all the devices within a network topology, okay? 15 00:44.080 --> 00:47.920 All that information is stored here, the type of devices, the IP addresses, the 16 00:47.920 --> 00:48.560 interfaces, 17 00:48.560 --> 00:53.260 so on and so forth, it's all in there. The client here wants to get that 18 00:53.260 --> 00:54.000 information. 19 00:54.000 --> 00:58.320 But let's maybe say we want to tell the server hey, the type of information I 20 00:58.320 --> 00:59.360 want is I want this 21 00:59.360 --> 01:05.120 coming back to me formatted in JSON. We tell the server the type of response WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:59.360 --> 01:05.120 coming back to me formatted in JSON. We tell the server the type of response 22 01:05.120 --> 01:06.080 that we are willing to 23 01:06.080 --> 01:10.640 accept a JSON based response. And then for what, for reason, let's maybe say 24 01:10.640 --> 01:11.840 that we make a request, 25 01:11.840 --> 01:15.530 and this time we want to get the response back for whatever request we have 26 01:15.530 --> 01:15.840 made, 27 01:15.840 --> 01:21.600 depending on the URI. We want the data coming back to us in XML. Once again, we 28 01:21.600 --> 01:22.720 can tell the server 29 01:22.720 --> 01:26.190 what we're willing to accept via the accept header, really quick 30 01:26.190 --> 01:27.440 straightforward. 31 01:27.440 --> 01:31.680 Now let's suppose we wanted to do something a little bit different, okay? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 31 01:27.440 --> 01:31.680 Now let's suppose we wanted to do something a little bit different, okay? 32 01:31.680 --> 01:35.760 So now as opposed to the client making a request to a server and saying hey can 33 01:35.760 --> 01:36.560 I get back some 34 01:36.560 --> 01:42.120 information in JSON or XML, what if we wanted to modify the contents within a 35 01:42.120 --> 01:43.360 server? Well, 36 01:43.360 --> 01:47.880 we can make a post request as we do not create any resource. Now at this stage 37 01:47.880 --> 01:48.240 here, 38 01:48.240 --> 01:51.740 along with the request, we're going to actually have to send some type of 39 01:51.740 --> 01:53.040 payload, which is going to be 40 01:53.040 --> 01:56.710 the data that we're trying to insert into the server. Now because we are not 41 01:56.710 --> 01:58.080 just making a request, 42 01:58.080 --> 02:02.420 it simply retrieves some information from the server, but also including WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 01:58.080 --> 02:02.420 it simply retrieves some information from the server, but also including 43 02:02.420 --> 02:03.360 content of our own. 44 02:03.360 --> 02:09.130 What we want to do is we want to tell the server the type of content to expect. 45 02:09.130 --> 02:09.680 Now the way we do 46 02:09.680 --> 02:15.770 this is once again via header, this time known as a content type header. Now 47 02:15.770 --> 02:16.960 consider this again, 48 02:16.960 --> 02:21.520 client server. Let's imagine we have some very sensitive data on this server, 49 02:21.520 --> 02:22.720 okay? Now think about it, 50 02:22.720 --> 02:26.200 should this client be able to just reach into this server and read this 51 02:26.200 --> 02:27.840 potentially sensitive data, 52 02:27.840 --> 02:33.280 or maybe even modify this sensitive data without really having to prove who WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 52 02:27.840 --> 02:33.280 or maybe even modify this sensitive data without really having to prove who 53 02:33.280 --> 02:34.240 they actually are to 54 02:34.240 --> 02:39.290 prove their credentials, so to speak. Not really, this would be a pretty bad 55 02:39.290 --> 02:40.480 idea. So what we can 56 02:40.480 --> 02:44.830 actually do is pass on the credentials via an authorization header, and this is 57 02:44.830 --> 02:45.600 exactly as it 58 02:45.600 --> 02:49.260 sounds a way for you to authenticate with the server you're trying to talk to. 59 02:49.260 --> 02:50.000 Now one crucial point 60 02:50.000 --> 02:54.310 to note is that you don't have to use one of these headers in place of another, 61 02:54.310 --> 02:55.280 you can actually use 62 02:55.280 --> 02:59.700 multiple headers together. So you could pass in your authentication credentials 63 02:59.700 --> 03:01.280 within the authorization WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 63 02:59.700 --> 03:01.280 within the authorization 64 03:01.280 --> 03:05.210 header, and at the same time specify a content type, you know, saying I'm going 65 03:05.210 --> 03:06.480 to be sending you some 66 03:06.480 --> 03:10.860 JSON data. And now the server knows to expect JSON data, and the server also 67 03:10.860 --> 03:12.640 knows that the client 68 03:12.640 --> 03:16.990 is actually allowed to make a request because they have been authorized. This 69 03:16.990 --> 03:17.760 is a type of thing 70 03:17.760 --> 03:21.780 that we do with our headers. Okay, now next point, this is a really important 71 03:21.780 --> 03:22.720 concept, because we're 72 03:22.720 --> 03:27.730 dealing with rest, we're dealing with HTTP, and HTTP has some very specific 73 03:27.730 --> 03:29.680 response codes. Essentially, 74 03:29.680 --> 03:34.040 what I'm talking about here is when our client goes and sends off a particular WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 74 03:29.680 --> 03:34.040 what I'm talking about here is when our client goes and sends off a particular 75 03:34.040 --> 03:35.360 request to the server. 76 03:35.360 --> 03:40.000 The server is always going to respond with some type of response code, now this 77 03:40.000 --> 03:40.800 is going to be a 78 03:40.800 --> 03:45.700 three digit number that ultimately describes the state of the request itself. 79 03:45.700 --> 03:47.040 So three digit number, 80 03:47.040 --> 03:50.560 let's say the first digit starts with a one. Okay, let's forget about the last 81 03:50.560 --> 03:51.360 two digits right now, 82 03:51.360 --> 03:56.120 but let's just say if it starts with a one, this is a particular class of 83 03:56.120 --> 03:57.600 response, and this class 84 03:57.600 --> 04:01.860 of response is known as an informational response code. Essentially, this is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 84 03:57.600 --> 04:01.860 of response is known as an informational response code. Essentially, this is 85 04:01.860 --> 04:03.120 the server's way of 86 04:03.120 --> 04:07.380 saying to you, hey, I got your request. It is valid. There's no problem here, 87 04:07.380 --> 04:08.560 but I'm still waiting for 88 04:08.560 --> 04:12.240 some information. Now the next two digits, they actually tell you what is 89 04:12.240 --> 04:13.520 happening with a little 90 04:13.520 --> 04:18.180 bit more specificity. So say, for example, you receive a 100 status code, the 91 04:18.180 --> 04:19.200 first number here 92 04:19.200 --> 04:23.550 tells you again, it's informational, but the remaining two digits, this 93 04:23.550 --> 04:24.800 actually correlates to a 94 04:24.800 --> 04:29.030 very particular response. What this response actually means, it's the way of 95 04:29.030 --> 04:30.080 the server telling the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 95 04:29.030 --> 04:30.080 the server telling the 96 04:30.080 --> 04:34.410 client to simply continue. So you can imagine if the client was sending a ton 97 04:34.410 --> 04:35.520 of information to the 98 04:35.520 --> 04:39.450 server right here, and basically you want to assess that the server is not 99 04:39.450 --> 04:41.200 actually rejecting anything, 100 04:41.200 --> 04:44.290 and we just want to be sure that it's ready to continue and process more 101 04:44.290 --> 04:45.280 information. Then we 102 04:45.280 --> 04:49.550 can wait to get this 100 status code. And if we do get that, then that 103 04:49.550 --> 04:50.960 indicates that everything 104 04:50.960 --> 04:55.670 is as expected, and then we can continue on sending more data. Whereas if we 105 04:55.670 --> 04:57.280 get the next class of 106 04:57.280 --> 05:01.410 status codes, this is going to start with a two. So if your response happens to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 106 04:57.280 --> 05:01.410 status codes, this is going to start with a two. So if your response happens to 107 05:01.410 --> 05:02.400 begin with the number 108 05:02.400 --> 05:07.090 two, you should begin clicking your heels and celebrating what this actually 109 05:07.090 --> 05:08.240 denotes, is that we have 110 05:08.240 --> 05:12.850 had a successful request, everything is as expected. Okay. Now once again, the 111 05:12.850 --> 05:14.160 first digit tells you 112 05:14.160 --> 05:18.090 the class is successful, but the next two digits tell you very specifically 113 05:18.090 --> 05:19.680 what the success was. 114 05:19.680 --> 05:24.950 So again, let's imagine we have our client over here and the server over here, 115 05:24.950 --> 05:25.520 and we happen to 116 05:25.520 --> 05:30.220 send, let's go with an HTTP get request, that's the method we use, and we have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 116 05:25.520 --> 05:30.220 send, let's go with an HTTP get request, that's the method we use, and we have 117 05:30.220 --> 05:31.520 our authorization 118 05:31.520 --> 05:35.180 and play, we have our accept header, so on so forth. When the server actually 119 05:35.180 --> 05:36.160 sends back the data 120 05:36.160 --> 05:40.100 we were looking for, we're also going to see in the response the status code of 121 05:40.100 --> 05:41.600 200, and a 200 122 05:41.600 --> 05:45.750 response is just correlating to okay pretty much the server is saying to you, 123 05:45.750 --> 05:46.560 everything was good, 124 05:46.560 --> 05:51.100 no problems at all. So this is what we can expect with the get request, however 125 05:51.100 --> 05:51.840 , let's imagine 126 05:51.840 --> 05:55.690 things were a little bit different. We then send a new request to the server, 127 05:55.690 --> 05:56.640 this time we send 128 05:56.640 --> 06:00.540 a post request, so again we will have our content type headers, maybe we've got WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 128 05:56.640 --> 06:00.540 a post request, so again we will have our content type headers, maybe we've got 129 06:00.540 --> 06:01.600 our authorization 130 06:01.600 --> 06:05.450 headers, and the data that we're trying to insert into the server, this has 131 06:05.450 --> 06:06.640 been accepted, so what 132 06:06.640 --> 06:09.450 we're going to do is we're going to get a response back and in that response we 133 06:09.450 --> 06:10.160 're going to see a 134 06:10.160 --> 06:14.530 status code, and once again, as you may expect, that status code is going to 135 06:14.530 --> 06:15.520 begin with a two, 136 06:15.520 --> 06:20.370 this time though, the next two digits are going to be 0, 1. This particular 137 06:20.370 --> 06:21.600 status code denotes 138 06:21.600 --> 06:26.360 that we have a success, but also that a resource was created. So you wouldn't 139 06:26.360 --> 06:27.440 expect to see this 140 06:27.440 --> 06:31.130 status code with the get request, which are not creating a resource, but for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 140 06:27.440 --> 06:31.130 status code with the get request, which are not creating a resource, but for 141 06:31.130 --> 06:32.080 something like say a 142 06:32.080 --> 06:36.630 post request, this is the type of response you would want, and all the server 143 06:36.630 --> 06:37.520 is doing here is 144 06:37.520 --> 06:41.300 giving you really clear information. So three more categories, let's blitz 145 06:41.300 --> 06:42.480 through them then, 146 06:42.480 --> 06:46.880 once again we send off a request to our server, the server responds this time 147 06:46.880 --> 06:47.760 with a status code 148 06:47.760 --> 06:52.020 beginning with the number three, what this class of status code denotes is that 149 06:52.020 --> 06:53.360 we have a redirection 150 06:53.360 --> 06:58.100 okay, so let's imagine we get a 301 status code again, three tells us it's a 151 06:58.100 --> 06:59.840 redirection, and a 301 152 06:59.840 --> 07:04.300 tells us is that the resource we're looking for has moved permanently okay, so WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 06:59.840 --> 07:04.300 tells us is that the resource we're looking for has moved permanently okay, so 153 07:04.300 --> 07:05.120 the thing you were 154 07:05.120 --> 07:08.920 looking for is not at that end point anymore, if you want to get it, well you 155 07:08.920 --> 07:09.840 're going to have to 156 07:09.840 --> 07:15.990 make a modification, whereas if we happen to maybe get a 307 response, this is 157 07:15.990 --> 07:16.880 actually telling us 158 07:16.880 --> 07:21.460 that the resource has moved temporarily, so perhaps if you wait a little bit, 159 07:21.460 --> 07:22.640 resend the request, 160 07:22.640 --> 07:27.190 maybe you will be successful, so again the difference here, and the status code 161 07:27.190 --> 07:28.560 telling us the 162 07:28.560 --> 07:32.290 condition of the actual response, now the next status code is the ones that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 162 07:28.560 --> 07:32.290 condition of the actual response, now the next status code is the ones that 163 07:32.290 --> 07:33.680 begin with the four, 164 07:33.680 --> 07:38.050 this actually tells us that we have some type of client error, basically that 165 07:38.050 --> 07:39.280 means that on our end 166 07:39.280 --> 07:44.310 over here, the actual request that we sent was in valid or some problem with it 167 07:44.310 --> 07:45.280 , so as we know, 168 07:45.280 --> 07:48.730 the last two digits are going to tell us more about what that client error 169 07:48.730 --> 07:50.320 actually is, so say for 170 07:50.320 --> 07:54.880 example, if we get a four or one status code, this is a client error, and it 171 07:54.880 --> 07:56.080 pretty much tells us is 172 07:56.080 --> 08:00.290 that the server is rejecting a request because we actually do not have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 172 07:56.080 --> 08:00.290 that the server is rejecting a request because we actually do not have 173 08:00.290 --> 08:01.920 authorization, so maybe you 174 08:01.920 --> 08:05.060 forgot to put in your authorization header, maybe you put in the wrong 175 08:05.060 --> 08:07.040 information within that header, 176 08:07.040 --> 08:10.770 for whatever reason, the server is telling you you're not authorized, and it 177 08:10.770 --> 08:11.600 really is telling you 178 08:11.600 --> 08:15.170 that you look at the status code, four or one, you know straight away, hey I 179 08:15.170 --> 08:16.160 better find out what 180 08:16.160 --> 08:20.130 my authorization is, and then maybe give it a double check, and again if you 181 08:20.130 --> 08:21.200 maybe make a request 182 08:21.200 --> 08:25.450 and you get a four or four, this is telling you that the resource that you're 183 08:25.450 --> 08:26.560 trying to get on the 184 08:26.560 --> 08:30.250 server was not found, so maybe you should go and check the URL that you're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 184 08:26.560 --> 08:30.250 server was not found, so maybe you should go and check the URL that you're 185 08:30.250 --> 08:31.440 using because what you're 186 08:31.440 --> 08:35.320 trying to request here is simply not found, sounds like you've got a problem, 187 08:35.320 --> 08:36.480 so the next and final 188 08:36.480 --> 08:41.760 category is the 500 status code, so again starts the five, this category here 189 08:41.760 --> 08:43.120 is for when the server 190 08:43.120 --> 08:46.580 itself happens to have an error, and again the next two digits tell you more 191 08:46.580 --> 08:47.760 information if you happen 192 08:47.760 --> 08:52.610 to see a 500 status code, this tells you that the server here happens to have 193 08:52.610 --> 08:53.760 had some type of 194 08:53.760 --> 08:59.170 internal server error, it's not used to client, the problem is very much over 195 08:59.170 --> 09:00.480 here, whereas maybe WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 195 08:59.170 --> 09:00.480 here, whereas maybe 196 09:00.480 --> 09:04.210 let's say you make a request to a server trying to do, let's go with a put 197 09:04.210 --> 09:05.440 request to update some 198 09:05.440 --> 09:09.760 information, and the actual API right here for whatever reason has not actually 199 09:09.760 --> 09:10.960 implemented that type 200 09:10.960 --> 09:15.480 of method, basically it does not support the updating of information via a put 201 09:15.480 --> 09:16.560 request, then the 202 09:16.560 --> 09:21.500 status code that you would see would be a 501 status code telling you that the 203 09:21.500 --> 09:22.480 method that you're 204 09:22.480 --> 09:27.520 using is not implemented, but it might actually be implemented later on down 205 09:27.520 --> 09:29.040 the line in the future, 206 09:29.040 --> 09:32.560 so as you can see these are some very important components of a rest API WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 206 09:29.040 --> 09:32.560 so as you can see these are some very important components of a rest API 207 09:32.560 --> 09:34.080 utilizing our headers, 208 09:34.080 --> 09:37.600 telling us a type of information we expect to receive the type of information 209 09:37.600 --> 09:38.640 we're going to send, 210 09:38.640 --> 09:42.400 as well as how we can authenticate with our server, and the server will always 211 09:42.400 --> 09:43.360 give us back some 212 09:43.360 --> 09:47.840 really insightful information about a request via our status codes, remember 213 09:47.840 --> 09:48.800 the first digit will 214 09:48.800 --> 09:52.500 tell you the class of response, and then the remaining two digits will tell you 215 09:52.500 --> 09:53.600 the very specific 216 09:53.600 --> 09:57.640 category of that class, so that you know exactly why the server responded the 217 09:57.640 --> 09:58.880 way it did.