WEBVTT 0 00:00.630 --> 00:01.280 All right, guys. 1 00:01.320 --> 00:08.490 So in this module, we're going to learn all about how to build your very own RESTful API. 2 00:09.180 --> 00:15.990 Now, in previous modules, we've seen and used APIs that other people have created, and we've also 3 00:15.990 --> 00:21.170 started to build up our server to allow get requests and post requests. 4 00:21.570 --> 00:27.240 But in this module, we're going to do it from beginning to end and we're going to build our very own 5 00:27.240 --> 00:29.160 complete RESTful API. 6 00:29.640 --> 00:35.430 Now, the first question you might have is what exactly does REST mean and what does it mean to make 7 00:35.430 --> 00:37.100 an API RESTful, 8 00:37.140 --> 00:37.470 right? 9 00:37.920 --> 00:44.850 Well, REST is not lazing on the couch and watching Netflix, but it actually stands for REpresentational 10 00:44.850 --> 00:48.630 State Transfer, which is quite a mouthful. 11 00:48.630 --> 00:54.480 But in order to understand it, we have to backtrace a little bit and we have to go back to that classic 12 00:54.480 --> 00:59.630 architecture that we already looked at, which is the client and server architecture. 13 00:59.820 --> 01:03.840 And this is the architecture that the entire Internet is pretty much built on. 14 01:04.380 --> 01:09.210 So let's just review it quickly. So the client makes a request to the server. 15 01:09.450 --> 01:11.130 So what exactly is the client? 16 01:11.160 --> 01:16.710 Well, if we were in a restaurant, the client would be, well, the client who's paying for the meal, 17 01:16.710 --> 01:17.030 right? 18 01:17.310 --> 01:20.830 And the server would be the server staff at the restaurant. 19 01:21.390 --> 01:27.420 So when our client makes a request, say, I'd like a pizza please, then the server has to check 20 01:27.420 --> 01:30.510 to see if this is something that the restaurant can fulfill. 21 01:30.780 --> 01:35.330 And if so, he will smile graciously at you and fulfill that request. 22 01:35.670 --> 01:41.310 But if the client requested something that they didn't have, for example, a sausage, and it's not on 23 01:41.310 --> 01:48.420 the menu, then the server would give you a error code, a classic one, of course, being 404, which 24 01:48.420 --> 01:50.640 is resource doesn't exist. 25 01:50.670 --> 01:58.280 We don't stock sausages. Now when the client makes that request to the server classically on the Internet, 26 01:58.290 --> 02:04.050 this is done through a HTTP request, hypertext transfer protocol request. 27 02:04.680 --> 02:10.860 And the analogy for this is it's kind of like the language that you're using to make the request, say 28 02:10.860 --> 02:13.110 you're saying I want a pizza, 29 02:13.110 --> 02:13.410 right? 30 02:13.590 --> 02:17.880 And if you're in France, you would have to say that in French, although I'm not sure what you're doing 31 02:17.880 --> 02:22.890 eating pizzas in France. But the server would be able to understand your request and give you back 32 02:22.890 --> 02:24.120 the correct result. 33 02:24.630 --> 02:31.800 Now, the thing you have to remember is that HTTP, this hypertext transfer protocol, is not the only 34 02:31.800 --> 02:34.230 language that servers can speak, 35 02:34.230 --> 02:34.570 right? 36 02:34.830 --> 02:40.830 Another one that you might have heard of is, for example, the FTP request, which is the file transfer 37 02:40.830 --> 02:41.860 protocol request. 38 02:42.360 --> 02:47.340 So if you use the wrong language, you might not get back the result that you're looking for. 39 02:47.730 --> 02:54.810 So, for example, if a server speaks French in France and you try to speak to him in Italian, that 40 02:54.810 --> 02:56.050 probably won't work. 41 02:56.280 --> 03:01.410 So we have to make sure we've got the right language for making our request. 42 03:01.800 --> 03:07.350 Now, at this point, some students might say, well, what about that other thing that HTTPs 43 03:07.410 --> 03:08.550 request? 44 03:08.820 --> 03:09.310 What does that 45 03:09.310 --> 03:10.380 s stand for, 46 03:10.410 --> 03:11.820 and is it a different language? 47 03:12.210 --> 03:16.760 Well, HTTPs stands for HTTP secure request. 48 03:17.010 --> 03:23.700 So remember that all your requests and responses are going across the Internet and can be potentially 49 03:23.700 --> 03:25.670 tapped in by lots of people. 50 03:25.980 --> 03:32.160 So if you wanted to make it secure so you don't want to be on a website entering your card details and 51 03:32.160 --> 03:38.640 it's just going through, you know, a bog-standard HTTP request because somebody might hijack that 52 03:38.640 --> 03:40.970 along the way and that's not very secure. 53 03:41.130 --> 03:45.020 So we can also use cryptography and encrypt our request 54 03:45.240 --> 03:49.980 so if anybody does intercept the request, they won't be able to know what it says. 55 03:50.550 --> 03:54.510 Now, this is kind of equivalent to having like a secret code language. 56 03:54.870 --> 04:01.290 For example, if both you and your waiter speak Klingon, then you could communicate securely 57 04:01.590 --> 04:06.510 and it doesn't matter if you're overheard in the restaurant because nobody else will be able to understand 58 04:06.690 --> 04:09.660 what you're saying other than yourself and your waiter. 59 04:09.900 --> 04:15.690 Now, let's say that the client has successfully made the request to the server and this is something 60 04:15.690 --> 04:18.090 that the server can serve up, 61 04:18.300 --> 04:22.110 so it sees it as a valid request instead of a 404, 62 04:22.470 --> 04:28.020 then in this case the server should respond with the results of what it is that you requested. 63 04:28.590 --> 04:35.160 So in the restaurant, that might be your pizza. But on the Internet, that might be the web page HTML 64 04:35.370 --> 04:39.300 or resources such as images or data. 65 04:39.570 --> 04:44.610 Now, in order to give us that result, the server might do one of two things. 66 04:44.610 --> 04:49.980 It might do some computation, run some code to work out the result that you need 67 04:50.130 --> 04:57.780 for example, if our server was a simple calculator web application, or the server might need to communicate 68 04:57.780 --> 04:59.970 with our database in order to grab 69 05:00.030 --> 05:06.360 the relevant pieces of data that the client requested. So depending on what kind of request that the 70 05:06.360 --> 05:13.320 client made, what kind of resource they wanted, the server might do one or both of these things. 71 05:13.680 --> 05:21.330 So we've seen that the client has to talk to the server using an HTTP request, a specific language that 72 05:21.330 --> 05:22.590 the server can understand. 73 05:23.130 --> 05:28.230 But also, there's only a certain amount of things that the server can do, right? 74 05:28.440 --> 05:34.320 Say at a restaurant, you would have a menu of items that this particular restaurant would serve. 75 05:34.440 --> 05:36.830 And it's exactly the same on the Internet. 76 05:37.380 --> 05:45.030 The server will have a whole bunch of APIs which are services that it can expose for clients to be able 77 05:45.030 --> 05:45.900 to tap into. 78 05:46.290 --> 05:48.300 And so when we're building an API 79 05:48.300 --> 05:54.540 we're kind of like building the menu of things that our server can respond to when a client makes a 80 05:54.540 --> 05:55.140 request. 81 05:55.470 --> 06:02.330 So now that we understand all three components, what does it mean to make our API RESTful? 82 06:02.970 --> 06:07.130 Well, REST is essentially just an architectural style. 83 06:07.620 --> 06:13.830 So just as you have different buildings that have different architectural styles, for example, the 84 06:13.830 --> 06:20.580 Baroque architectural style with the nice arches or other buildings might be built in the Gothic architectural 85 06:20.580 --> 06:24.930 style with flying buttresses and these imposing beams. 86 06:25.200 --> 06:32.100 And my favorite, the Neoclassical, have these incredibly geometric shapes and columns that really 87 06:32.100 --> 06:34.690 remind you of old Greek architecture. 88 06:35.610 --> 06:40.550 So these are architectural styles for designing buildings. 89 06:40.890 --> 06:48.600 Well, REST is an architectural style for designing APIs, and it's definitely not the only architectural 90 06:48.600 --> 06:48.960 style. 91 06:49.380 --> 06:55.800 So the other really, really popular one before REST became the dominant style was SOAP. 92 06:56.160 --> 07:02.280 And there's also GraphQL or FALCOR and there's a lot of other architectural styles. 93 07:02.550 --> 07:06.240 But the gold standard for Web APIs is REST. 94 07:06.420 --> 07:08.370 So that's what we're going to be looking at. 95 07:08.610 --> 07:15.400 And REST actually came about really quite recently as a part of this guy's Ph.D. 96 07:15.480 --> 07:20.580 This is Roy Fielding and he did his PhD in the University of California. 97 07:20.820 --> 07:26.430 And as a part of his doctorate, he researched and came up with this architectural style that we now 98 07:26.430 --> 07:27.240 call REST. 99 07:27.570 --> 07:33.720 And it proposes a set of rules that web developers could follow when they're building their APIs. 100 07:34.140 --> 07:41.430 And he came up with this idea that all websites across the web would use the same structure for building 101 07:41.430 --> 07:42.260 their APIs. 102 07:42.720 --> 07:48.240 I mean, imagine if you had a whole street and all their buildings had the same layout. 103 07:48.540 --> 07:53.220 For example, the toilets for men and women are always on the same floors, in the same position, 104 07:53.310 --> 07:57.750 then you would never get into a situation where you're trying to find the toilet. 105 07:58.080 --> 08:04.200 So my personal struggles aside, essentially in his Ph.D. he proposed that the Internet could do the 106 08:04.200 --> 08:04.740 same. 107 08:05.010 --> 08:11.610 If every Web API was built using the same common guiding principles, then it would be so easy for everybody 108 08:11.610 --> 08:16.890 to work together and be able to use different APIs quickly, easily, and efficiently. 109 08:17.070 --> 08:19.310 So pretty neat for a PhD project, right? 110 08:19.530 --> 08:21.180 There's definitely some PhD projects 111 08:21.190 --> 08:26.370 that are a lot worse like the guy who had to look into the propulsion parameters of penguin poop. 112 08:26.850 --> 08:29.040 But maybe if you really like penguins, that's OK. 113 08:30.870 --> 08:34.500 So how exactly do we make our API RESTful? 114 08:34.950 --> 08:40.890 Well, there's a lot of rules that an API has to follow to be RESTful. 115 08:41.460 --> 08:47.160 And just as you have rules that you might follow at your workplace or your school, you might have a 116 08:47.160 --> 08:51.390 uniform, no shorts, no singlets, don't smoke in the building, 117 08:52.860 --> 08:57.180 you also have a whole bunch of rules for making an API RESTful. 118 08:57.570 --> 09:03.510 But the two most important ones are using the HTTP request verbs, 119 09:03.630 --> 09:14.340 so using that HTTP request language, and also to use a specific pattern of routes and endpoint URLs. 120 09:15.120 --> 09:22.070 And these two things are probably the most important parts of making your API restful. 121 09:22.080 --> 09:24.190 And we're going to look at each of them in detail. 122 09:24.540 --> 09:28.450 So first, what exactly are the HTTP verbs? 123 09:28.470 --> 09:30.160 Well, you've already seen some of them. 124 09:30.630 --> 09:40.020 First is GET, then is POST, PUT, and PATCH. PATCH came relatively recently in 2010 and it was added 125 09:40.020 --> 09:44.610 to the HTTP request language essentially very recently. 126 09:44.640 --> 09:48.270 But it's kind of a neat twist on how we update data 127 09:48.270 --> 09:50.160 and we're going to look at that in a little bit as well. 128 09:50.580 --> 09:52.020 And finally, you've got DELETE. 129 09:52.200 --> 09:59.010 So these are the five HTTP verbs that you should be using in order to make your API RESTful. 130 09:59.310 --> 09:59.820 And you 131 10:00.070 --> 10:07.650 might realize that they have a lot of similarities to something that we covered previously in the database 132 10:07.650 --> 10:11.250 module, which is when we looked into CRUD, right? 133 10:11.250 --> 10:13.620 Create, read, update and delete. 134 10:14.370 --> 10:23.880 So we're going to look at our REST HTTP request verbs alongside our database CRUD functions and we're 135 10:23.880 --> 10:27.870 going to see how each of these verbs work in practice. 136 10:28.290 --> 10:35.640 So now that we've looked at the HTTP request verbs and we can see how they're used, the next thing 137 10:35.640 --> 10:42.330 to talk about is the specific pattern of routes and endpoints that you have to use in order to make 138 10:42.330 --> 10:43.720 your API RESTful. 139 10:44.070 --> 10:49.830 So just as when you go on a safari, there are different routes that you would use to reach say 140 10:49.830 --> 10:53.390 the elephant area or the camels or the hippos, in our server 141 10:53.670 --> 11:00.150 we can specify specific routes or URL's in order to access certain resources. 142 11:00.510 --> 11:07.470 So you might have, you know, www.google.com/elephants, then that would bring up all 143 11:07.470 --> 11:12.020 of the elephants and /camels would be for the camels and hippos. 144 11:12.240 --> 11:18.390 So these are routes and we've already used routes before in our server code. 145 11:18.630 --> 11:25.260 But in order for our API to be RESTful, we have to have a specific pattern of endpoints and routes. 146 11:25.440 --> 11:30.410 So, for example, if our API was the Wikipedia API, right? 147 11:30.600 --> 11:34.440 And in our database, we had a whole bunch of articles. 148 11:34.740 --> 11:40.780 Now the route for /articles applies to all of the articles. 149 11:40.950 --> 11:48.570 Now, if we created a route for articles, then when a client makes a get request to /articles, 150 11:48.780 --> 11:51.030 it should fetch all of the articles. 151 11:51.570 --> 11:58.290 And when they make a post request to the /articles route, then it should create a single 152 11:58.290 --> 11:59.490 new article 153 12:01.030 --> 12:08.680 and add it to our database of articles. And when we make a delete request to /articles, then it 154 12:08.680 --> 12:12.100 would delete all the articles in our database. 155 12:12.340 --> 12:17.440 But RESTful routing also has rules for individual resources. 156 12:17.650 --> 12:21.730 So within all of the articles, we will have specific articles, 157 12:21.730 --> 12:21.980 right? 158 12:22.180 --> 12:24.490 Say we had an article on Jack Bauer, 159 12:24.730 --> 12:32.530 then if the client was targeting /articles/Jack-Bauer, then if they made a get request, 160 12:32.620 --> 12:37.750 that would fetch the specific article on Jack Bauer from our database. 161 12:38.080 --> 12:44.590 And you can also use put and patch to update that specific article on Jack Bauer 162 12:44.800 --> 12:47.420 and you can delete the specific article as well. 163 12:47.590 --> 12:53.440 Now, a little bit later on, when we create all of these routes using the HTTP verbs, it's going to 164 12:53.440 --> 12:56.190 be a lot more clear how each of these work. 165 12:56.380 --> 13:02.230 But for now, I just want you to get an overview of what RESTful routing actually looks like before 166 13:02.230 --> 13:03.040 we get started. 167 13:03.370 --> 13:11.980 So now that we've seen how HTTP request verbs work and the pattern of routes that make your API RESTful, 168 13:12.370 --> 13:18.030 the next step is to get started and actually build our very own API. 169 13:18.550 --> 13:22.030 So for all of that and more, I'll see you on the next lesson.