WEBVTT 0 00:00.620 --> 00:01.320 All right guys. 1 00:01.350 --> 00:09.210 So in this module we're going to learn all about how to build your very own RESTful API. 2 00:09.210 --> 00:14.660 Now in previous modules we've seen and used APIs that other people have created. 3 00:15.060 --> 00:21.490 And we've also started to build up our server to allow get requests and post requests. 4 00:21.570 --> 00:27.210 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.300 --> 00:29.700 complete RESTful API. 6 00:29.700 --> 00:35.580 Now the first question you might have is what exactly does REST mean and what does it mean to make an 7 00:35.610 --> 00:37.150 API RESTful 8 00:37.170 --> 00:37.480 right? 9 00:37.950 --> 00:44.820 Well rest is not lazing on the couch and watching Netflix but it actually stands for REpresentational 10 00:44.820 --> 00:48.620 State Transfer which is quite a mouthful 11 00:48.690 --> 00:54.450 but in order to understand it we have to backtrack a little bit and we have to go back to that classic 12 00:54.480 --> 00:59.790 architecture that we really looked at which is the client and server architecture. 13 00:59.940 --> 01:04.310 And this is the architecture that the entire internet is pretty much built on. 14 01:04.410 --> 01:09.210 So let's just review it quickly. So the client makes a request to the server. 15 01:09.510 --> 01:11.160 So what exactly is the client? 16 01:11.190 --> 01:16.800 Well if we were in a restaurant the client would be well the client who's paying for the meal 17 01:16.800 --> 01:17.010 right? 18 01:17.400 --> 01:21.420 And the server would be the server staff at the restaurant. 19 01:21.420 --> 01:25.530 So when our client makes a request say "I'd like a pizza please" 20 01:25.590 --> 01:30.740 then the server has to check to see if this is something that the restaurant can fulfill 21 01:30.870 --> 01:35.580 and if so he will smile graciously at you and fulfill that request. 22 01:35.670 --> 01:41.370 But if the client requested something that they didn't have for example a sausage and it's not on the 23 01:41.370 --> 01:45.270 menu then the server would give you a error code. 24 01:45.270 --> 01:50.650 A classic one of course being 404 which is resource doesn't exist. 25 01:50.670 --> 01:52.940 "We don't stock sausages". 26 01:53.100 --> 01:59.460 Now when the client makes that request to the server classically on the internet this is done through 27 01:59.520 --> 02:04.330 a HTTP request, Hypertext Transfer Protocol request. 28 02:04.560 --> 02:11.730 And we've already seen this when we said app.get and then we have our callback with our request and 29 02:11.790 --> 02:14.700 result that is that request. 30 02:14.700 --> 02:20.460 And the analogy for this is it's kind of like the language that you're using to make the request. 31 02:20.460 --> 02:23.030 Say you're saying, "I want a pizza" 32 02:23.040 --> 02:23.580 right? 33 02:23.610 --> 02:27.810 And if you're in France you would have to say that in French although I'm not sure what you're doing 34 02:27.840 --> 02:33.390 eating pizzas in France but the server would be a to understand your request and give you back the correct 35 02:33.510 --> 02:34.590 result. 36 02:34.590 --> 02:41.730 Now the thing you have to remember is that HTTP, this Hypertext Transfer Protocol, is not the only 37 02:41.730 --> 02:44.880 language that servers can speak right? 38 02:44.880 --> 02:51.270 Another one that you might have heard of is for example the FTP request which is the file transfer protocol 39 02:51.270 --> 02:51.870 request. 40 02:52.320 --> 02:57.720 So if you use the wrong language you might not get back the result that you're looking for. 41 02:57.720 --> 03:04.440 So for example if a server speaks French in France and you try to speak to him in Italian, 42 03:04.560 --> 03:06.260 that probably won't work. 43 03:06.270 --> 03:11.790 So we have to make sure we've got the right language for making our request. 44 03:11.790 --> 03:18.780 Now at this point some students might say, "well what about that other thing, that HTTPs request?" 45 03:18.810 --> 03:20.350 What does that stand "s" for 46 03:20.400 --> 03:22.140 and is it a different language? 47 03:22.170 --> 03:30.960 Well HTTPs stands for each HTTP secure request so remember that all your requests and responses are going 48 03:30.960 --> 03:35.640 across the Internet and can be potentially tapped in by lots of people. 49 03:35.940 --> 03:42.090 So if you wanted to make it secure so you don't want to be on a website entering your car details and 50 03:42.090 --> 03:48.930 it's just going through you know a bog standard age HTTP request because somebody might hijack that along 51 03:48.930 --> 03:51.120 the way and that's not very secure. 52 03:51.120 --> 03:55.160 So we can also use cryptography and encrypt our request. 53 03:55.230 --> 04:00.530 So if anybody does intercept the request they won't be able to know what it says. 54 04:00.540 --> 04:06.960 Now this is kind of equivalent to having like a secret code language for example if both you and your 55 04:06.960 --> 04:13.650 waiter speak Klingon then you could communicate securely and it doesn't matter if you're overheard in 56 04:13.650 --> 04:18.450 the restaurant because nobody else will be able to understand what you're saying other than yourself 57 04:18.780 --> 04:19.910 and your waiter. 58 04:19.920 --> 04:25.620 Now let's say that the client has successfully made the request to the server and this is something 59 04:25.620 --> 04:28.170 that the server can serve up, 60 04:28.290 --> 04:35.100 so it sees it as a valid request instead of a 404, then in this case the server should respond 61 04:35.220 --> 04:38.560 with the results of what it is that you requested. 62 04:38.580 --> 04:45.960 So in the restaurant that might be your pizza, but on the Internet that might be the web page HTML 63 04:46.110 --> 04:49.750 or resources such as images or data. 64 04:49.770 --> 04:54.670 So in our code you would have already seen app.get and in the callback function 65 04:54.750 --> 05:01.110 we've got our request and our result and the result is what we get back from the server. 66 05:01.180 --> 05:08.020 Now in order to give us that result, the server might do one of two things. It might do some computation, 67 05:08.020 --> 05:11.730 run some code to work out the result that you need 68 05:11.770 --> 05:19.360 for example if our server was a simple calculator web application, or the server might need to communicate 69 05:19.360 --> 05:24.920 with our database in order to grab the relevant pieces of data that the client requested. 70 05:25.330 --> 05:32.200 So depending on what kind of request that the client made, what kind of resource they wanted, the server 71 05:32.230 --> 05:35.260 might do one or both of these things. 72 05:35.260 --> 05:42.520 So we've seen that the client has to talk to the server using an HTTP request, a specific language 73 05:42.760 --> 05:49.030 that the server can understand. But also there's only a certain amount of things that the server can 74 05:49.030 --> 05:49.480 do 75 05:49.480 --> 05:50.020 right? 76 05:50.080 --> 05:56.080 Say at a restaurant you would have a menu of items that this particular restaurant would serve, 77 05:56.140 --> 05:58.990 and it's exactly the same on the Internet. 78 05:58.990 --> 06:06.280 The server will have a whole bunch of APIs which are services that it can expose for clients to 79 06:06.280 --> 06:07.510 be able to tap into. 80 06:07.960 --> 06:14.500 And so when we're building an API we're kind of like building the menu of things that our server can respond 81 06:14.500 --> 06:17.100 to when a client makes a request. 82 06:17.110 --> 06:23.950 So now that we understand all three components, what does it mean to make our API RESTful? 83 06:24.610 --> 06:29.260 Well REST is essentially just an architectural style. 84 06:29.260 --> 06:36.010 So just as you have different buildings that have different architectural styles for example, the Baroque 85 06:36.070 --> 06:42.160 architectural style with the nice arches or other buildings might be built in the Gothic architectural 86 06:42.160 --> 06:46.820 style with flying buttresses and these imposing beams. 87 06:46.900 --> 06:54.130 And my favorite the Neoclassical have these incredibly geometric shapes and columns that really remind 88 06:54.130 --> 06:57.280 you of old Greek architecture. 89 06:57.280 --> 07:02.460 So these are architectural styles for designing buildings. 90 07:02.530 --> 07:10.150 Well REST is an architectural style for designing APIs and it's definitely not the only architectural 91 07:10.150 --> 07:10.940 style. 92 07:11.020 --> 07:18.040 So the other really really popular one before REST became the dominant style was SOAP. 93 07:18.160 --> 07:24.490 And there's also GraphQL or FALCOR and there's a lot of other architectural styles. 94 07:24.490 --> 07:28.320 But the gold standard for web API is REST. 95 07:28.390 --> 07:34.900 So that's what we're going to be looking at. And REST actually came about really quite recently as a 96 07:34.900 --> 07:37.420 part of this guy's PHD. 97 07:37.420 --> 07:39.160 This is Roy Fielding 98 07:39.310 --> 07:45.760 and he did his PHD in the University of California and as a part of his Doctorate he researched and 99 07:45.760 --> 07:49.390 came up with this architectural style that we now call REST. 100 07:49.600 --> 07:56.070 And it proposes a set of rules that web developers could follow when they're building their APIs. 101 07:56.170 --> 08:03.370 And he came up with this idea that all websites across the web would use the same structure for building 102 08:03.370 --> 08:04.740 their APIs. 103 08:04.750 --> 08:11.110 I mean imagine if you had a whole street and all their buildings had the same layout, for example the 104 08:11.110 --> 08:16.480 toilets for men and women are always on the same floors in the same position then you would never get 105 08:16.480 --> 08:20.050 into a situation where you're trying to find the toilet. 106 08:20.050 --> 08:26.650 So my personal struggles aside, essentially in his PHD, he proposed that the Internet could do the same. 107 08:27.040 --> 08:33.520 If every web API was built using the same common guiding principles then it would be so easy for everybody 108 08:33.520 --> 08:39.030 to work together and be able to use different APIs quickly, easily and efficiently. 109 08:39.040 --> 08:41.490 So pretty neat for a PHD project right? 110 08:41.500 --> 08:44.580 There's definitely some PHD projects that are a lot worse 111 08:44.590 --> 08:48.280 like the guy who had to look into the propulsion parameters of penguin poop. 112 08:48.790 --> 08:51.890 But maybe if you really like penguins that's OK. 113 08:52.810 --> 08:56.950 So how exactly do we make our API RESTful? 114 08:56.950 --> 09:05.800 Well there's a lot of rules that an API has to follow to be RESTful. And just as you have rules that 115 09:05.800 --> 09:12.130 you might follow at your workplace or your school you might have a uniform no shorts no singlets don't 116 09:12.130 --> 09:14.510 smoke in the building, 117 09:14.860 --> 09:19.220 you will also have a whole bunch of rules for making an API RESTful. 118 09:19.510 --> 09:25.570 But the two most important ones are using the HTTP request verbs, 119 09:25.600 --> 09:36.280 so using that HTTP request language and also to use a specific pattern of routes and endpoint URLs. 120 09:37.150 --> 09:46.660 And these two things are probably the most important parts of making your API RESTful. 121 09:46.660 --> 09:49.040 And we're going to look at each of them in detail. 122 09:49.060 --> 09:53.020 So first what exactly are the HTTP verbs? 123 09:53.020 --> 09:55.010 Well you've already seen some of them. 124 09:55.120 --> 10:04.850 First is GET, then there's POST, PUT and PATCH. PATCH came relatively recently in 2010 and it was added to 125 10:04.850 --> 10:09.120 the HTTP request language essentially very recently. 126 10:09.170 --> 10:14.270 But it's kind of a neat twist on how we update data and we're going to look at that in a little bit 127 10:14.270 --> 10:15.130 as well. 128 10:15.140 --> 10:16.700 And finally you've got DELETE. 129 10:16.730 --> 10:24.290 So these are the five HTTP verbs that you should be using in order to make your API RESTful. And you 130 10:24.290 --> 10:32.150 might realize that they have a lot of similarities to something that we covered previously in the database 131 10:32.150 --> 10:35.330 module which is when we looked into CRUD 132 10:35.410 --> 10:35.770 right? 133 10:35.780 --> 10:38.900 Create, read, update and delete. 134 10:38.900 --> 10:48.380 So we're going to look at our REST HTTP request verbs alongside our database CRUD functions and we're 135 10:48.380 --> 10:52.970 going to see how each of these verbs work in practice. 136 10:52.970 --> 10:58.000 So the first one is GET and GET is basically the same as read. 137 10:58.100 --> 11:04.250 So we've already written this code many many times. Every single time we want our server to serve up 138 11:04.250 --> 11:05.220 some resource 139 11:05.360 --> 11:12.440 we've been using app.get and then we pass a callback that responds the request and sends the result 140 11:12.440 --> 11:13.190 back. 141 11:13.460 --> 11:19.550 And if the request involved something that relates to our database then that's the equivalent of searching 142 11:19.550 --> 11:23.520 through our database and returning the data as the result. 143 11:23.570 --> 11:31.930 The next one is POST and POST corresponds to the create word in our CRUD functions. 144 11:32.030 --> 11:38.410 So whenever we've created a form on our website we've used app.poss and then we have our callback 145 11:38.450 --> 11:45.560 with our request and response. And when data is posted to our server then we create an entry in our database 146 11:45.710 --> 11:47.540 and we save that data for later. 147 11:47.750 --> 11:54.830 So in this case the request will contain the data and the response will simply be success or maybe an 148 11:54.890 --> 11:55.520 error code 149 11:55.520 --> 12:02.230 if there was a problem. The next one is PUT and PATCH and they both update our database. 150 12:02.480 --> 12:12.080 So we might have app.put or we might have app.patch and these two things both go into our database 151 12:12.440 --> 12:14.530 and update some pieces of data. 152 12:15.050 --> 12:18.130 So what is the difference between put and patch? 153 12:18.140 --> 12:19.890 Well here's a good analogy. 154 12:19.940 --> 12:27.020 Recently I went onto Amazon and I found a really nice looking bicycle and because I really wanted to 155 12:27.020 --> 12:32.600 poison my lungs by exercising around London, I clicked on the buy now button. 156 12:32.600 --> 12:40.550 So there I was super happy super excited for my bicycle to arrive and then on the day of arrival I open 157 12:40.550 --> 12:48.020 up that box and my bicycle was really messed up. The whole front wheel was broken so I'm not really sure 158 12:48.020 --> 12:53.480 what happened at the Amazon warehouse but I got in touch with them and I wanted to try and figure out 159 12:53.510 --> 12:55.190 how we can solve this problem. 160 12:55.250 --> 12:58.410 So there were two ways that they could fix this problem. 161 12:58.430 --> 13:02.780 Option one was they send me an entire new bike. 162 13:02.780 --> 13:10.640 So this is the equivalent of put. You're updating your database by sending an entire entry to replace 163 13:10.640 --> 13:12.360 the previous one. 164 13:12.410 --> 13:18.710 Now the other option Amazon offered was for them to simply send me a new tire. 165 13:18.700 --> 13:20.840 That was the only thing that was broken, 166 13:20.870 --> 13:22.670 the rest the bike was fine 167 13:22.670 --> 13:28.850 and in order to save the world from carbon emissions shipping a wheel is much better than shipping an 168 13:28.850 --> 13:30.830 entire bicycle. 169 13:30.830 --> 13:33.160 And this is the same as patch. 170 13:33.230 --> 13:40.670 So when you're sending a patch request to the server you're only sending the piece of data that needs 171 13:40.760 --> 13:45.990 to be updated. Instead of the entire entry that will be replaced 172 13:46.010 --> 13:49.710 you'll simply just updating the thing that needs to be updated. 173 13:49.730 --> 13:56.060 So when we see this in practice only to think back to this bicycle analogy and maybe it'll help you 174 13:56.090 --> 13:59.550 try to understand the difference between these two words. 175 13:59.750 --> 14:01.600 The final one is really simple. 176 14:01.610 --> 14:08.210 It's simply delete and that's the same as delete in CRUD and the code is as easy as app.delete and 177 14:08.210 --> 14:12.030 this just deletes or destroys a particular piece of data in our database. 178 14:12.440 --> 14:19.100 So now that we've looked at the HTTP request verbs and we can see how they're used 179 14:19.310 --> 14:26.060 the next thing to talk about is the specific pattern of routes and endpoints that you have to use in 180 14:26.060 --> 14:28.200 order to make your API RESTful. 181 14:28.280 --> 14:34.550 So just as when you go on a Safari there are different routes that you would use to reach say the elephant 182 14:34.580 --> 14:37.850 area or the camels or the hippos, in our server 183 14:37.850 --> 14:45.890 we can specify specific routes or URLs in order to access certain resources. So you might have 184 14:45.940 --> 14:53.480 you know www.google.com/elephants then that would bring up all of the elephants and 185 14:53.480 --> 14:56.450 /camels would be for the camels and hippos. 186 14:56.450 --> 15:04.790 So these are routes and we've already used route before using Express a Node in our server code. But 187 15:04.790 --> 15:11.370 in order for our API to be RESTful we have to have a specific pattern of endpoints and routes. 188 15:11.390 --> 15:20.660 So for example, if our API was the Wikipedia API right? And in our database we had a whole bunch of articles. 189 15:20.660 --> 15:26.900 Now the route for /articles applies to all of the articles. 190 15:26.900 --> 15:34.460 Now if we created a route for articles then when a client makes a get request to /articles 191 15:34.760 --> 15:41.120 it should fetch all of the articles. And when they make a post request to the /articles 192 15:41.120 --> 15:50.790 route then it should create a single new article and add it to our database of articles. And when we make 193 15:50.820 --> 15:59.160 a delete request to /articles then it would delete all the articles in our database. But RESTful 194 15:59.160 --> 16:03.560 routing also has rules for individual resources. 195 16:03.600 --> 16:08.130 So within all of the articles we will have specific articles right? 196 16:08.160 --> 16:10.900 Say we had an article on Jack Bauer, then 197 16:10.960 --> 16:18.930 if the client was targeting /articles /jack-bauer then if they made a get request that would 198 16:18.930 --> 16:27.360 fetch the specific article on Jack Bauer from our database. And you can also use put and patch to update 199 16:27.450 --> 16:33.570 that specific article on Jack Bauer and you can delete the specific article as well. 200 16:33.570 --> 16:40.020 Now a little bit later on when we create all of these routes using the HTTP verbs it's gonna be a lot 201 16:40.020 --> 16:42.250 more clear how each of these works. 202 16:42.360 --> 16:48.270 But for now I just want you to get an overview of what RESTful routing actually looks like before we 203 16:48.270 --> 16:49.340 get started. 204 16:49.350 --> 16:57.900 So now that we've seen how HTTP request verbs work and the pattern of routes that make your API RESTful, 205 16:58.290 --> 17:03.960 the next step is to get started and actually build our very own API. 206 17:04.530 --> 17:07.920 So for all of that and more, I'll see on the next lesson.