WEBVTT 00:00.390 --> 00:06.210 So like I just said, you've done an awesome thing, you have created this awesome Reddit clone called 00:06.300 --> 00:08.640 Zap It and it's really great. 00:08.670 --> 00:13.020 But I want to talk about the limitations and what's sort of missing here, and this will help us as 00:13.020 --> 00:14.400 we move forward. 00:14.430 --> 00:21.210 So if you create just an API like this, it's probably going to be pretty hard to get off the ground 00:21.210 --> 00:22.020 like people would. 00:22.110 --> 00:27.270 You would probably see an existing Web site that eventually offers an API option. 00:27.290 --> 00:27.440 Right. 00:27.480 --> 00:33.270 Like, you would build a zap it Web site in Django, have that up for a while, but then you say, hey, 00:33.300 --> 00:37.530 I'm going to, you know, make an API so people can make their own mobile clients or something like 00:37.530 --> 00:37.710 that. 00:37.740 --> 00:42.420 So that's sort of thing one is, you know, how does someone understand this API? 00:42.550 --> 00:47.430 And a big thing here is I think really, if you're going to have an API that's out for the public to 00:47.430 --> 00:52.260 use, you've got to have some sort of documentation that lists, you know, information about the API 00:52.290 --> 00:53.700 so they know what to expect. 00:53.730 --> 00:59.700 Now, the Jenko rest framework gives you a lot of good information, like if someone comes to, you 00:59.700 --> 01:04.050 know, this page, The Post, Lyssa says, oh, look, I can do aget or a posten. 01:04.350 --> 01:06.540 You know, as they move different places, they can see that. 01:06.570 --> 01:09.180 But it's still not enough, in my opinion. 01:09.180 --> 01:11.700 I think it's better to have some logit documentation. 01:11.730 --> 01:16.380 Remember when we looked at the Twitter documentation like wuv, they really talked about everything. 01:16.830 --> 01:27.780 The next step here is that there is no way via the API for us to be able to log in or sign up for an 01:27.780 --> 01:29.580 account via the API. 01:29.610 --> 01:29.880 Right. 01:29.910 --> 01:38.100 So if you imagine someone was making a mobile app for our Zap It service and they were going to, you 01:38.100 --> 01:41.160 know, let people make accounts on the, you know, the mobile app. 01:41.490 --> 01:42.900 We don't have anything in place for that. 01:42.930 --> 01:45.270 We don't have anything in place if someone wants to log in. 01:45.320 --> 01:53.370 Now, technically, we do have a way for users to make those requests without being signed in, because 01:53.370 --> 01:59.220 everything that's happening via the sign in is currently happening visually here inside of the browser. 01:59.250 --> 02:08.370 But you'll notice, for example, let's say that I want to, you know, go ahead and like create a post 02:08.460 --> 02:10.470 and I want to do this via Curl. 02:10.620 --> 02:16.130 So this is where I talked about, you know, having your own rest client vs., you know, Kerl it's 02:16.130 --> 02:18.720 going to be a lot more convenient with the rest of rest client. 02:18.740 --> 02:24.150 In fact, I went ahead and made one via one of my programs and then just copied the code to a kernel 02:24.150 --> 02:24.600 command. 02:25.140 --> 02:31.830 This is essentially what we'd have to type into the terminal in order to get this to work. 02:31.860 --> 02:34.320 So you can go ahead and do the same thing. 02:34.830 --> 02:39.510 Basically with Kerl, we're saying, okay, you know, the really basic one when we just do a get for 02:39.510 --> 02:41.730 you URL, we don't have to do any of the special stuff. 02:41.760 --> 02:44.510 But if we're doing a post we have to do the dash capital X. 02:44.520 --> 02:47.670 That's a post in because we're passing it, Jason. 02:47.760 --> 02:54.150 We have to say, you know, this has a content type of Jason because we have a user that this is where 02:54.150 --> 02:54.630 I'm showing you. 02:54.650 --> 02:56.740 You can't log in via this API. 02:56.790 --> 03:02.100 But if I pass in that the user is zappy code and the password is this and then I pass forward the data 03:02.100 --> 03:04.600 like, you know, this is the title and this is the euro. 03:04.650 --> 03:12.270 If I have all of this when I go ahead and copy this and I come to my terminal, make sure your servers 03:12.270 --> 03:12.520 running. 03:12.600 --> 03:17.550 But in a separate terminal tab, I'm going to paste in all this Kerl thing and go ahead and hit enter 03:17.550 --> 03:18.210 in on this. 03:18.690 --> 03:20.270 It's going to make an object like. 03:20.450 --> 03:23.100 So that part of the API is functional. 03:23.700 --> 03:28.260 And if we go ahead and, you know, go back to the post lists here, you can see, oh, look at, you 03:28.260 --> 03:30.210 know, just added what we created here. 03:32.280 --> 03:36.570 But at least in my opinion, this isn't really ideal in this also. 03:37.470 --> 03:40.590 What I'm talking about, the limitations of the API and what we have here. 03:41.040 --> 03:43.230 These are going to be addressed in the next section. 03:43.260 --> 03:44.220 In the next section. 03:44.280 --> 03:45.960 I have an existing project. 03:45.960 --> 03:48.390 It's a an app that's a to do list. 03:48.420 --> 03:49.640 I call it to do. 03:49.830 --> 03:51.720 This is from my Django three course. 03:51.960 --> 03:54.720 And I'm going to give you this completely ready to go. 03:55.020 --> 03:58.860 Web site that's made in Django but has zero API. 03:58.920 --> 04:02.790 And then we're going to fill in the API for that site. 04:02.840 --> 04:09.730 And we're going to address things like, you know, letting people sign up for the service via the API. 04:09.750 --> 04:15.780 Being able to log in and using something called authentication tokens so that when they're making requests, 04:15.780 --> 04:18.170 we don't have to always pass in the username and password. 04:18.180 --> 04:22.250 Like, at least in my opinion, I think it's really bad API design. 04:22.260 --> 04:29.040 If we have to always be passing the username and the password inside of that request, like, you know, 04:29.310 --> 04:34.020 if everything's over H TDP s and the, you know, developers really secure with how they store that 04:34.020 --> 04:34.560 password. 04:34.980 --> 04:35.620 That's probably OK. 04:35.730 --> 04:41.190 But a much better solution is have you know if the user enters in their username and password, send 04:41.190 --> 04:46.890 that over to the API, get an authentication token and then just have to store that token, which can 04:46.890 --> 04:48.690 be destroyed or updated at any point. 04:48.710 --> 04:50.580 We'll talk about that in the next section. 04:50.610 --> 04:54.870 But basically wanted to say EFF gone on pretty long here. 04:55.170 --> 04:58.230 Congratulations on making your very first API. 04:58.260 --> 04:59.460 Hopefully the sparks. 04:59.800 --> 05:03.650 Some imagination you to think, you know, how can I apply this in my projects? 05:04.280 --> 05:09.560 But, you know, I think it's really going to become valuable here as we move into the next section 05:09.560 --> 05:14.930 and talk about, you know, how we apply this to an existing project, because I'm guessing most of 05:14.930 --> 05:17.270 the time that's going to be your situation. 05:17.390 --> 05:18.440 Not always the case. 05:18.470 --> 05:25.510 There's a lot of front end frameworks where if you just create a rest API, you can build all your Web 05:25.510 --> 05:31.310 site visual things over that API so that, you know, your Web site is essentially a client, just like 05:31.310 --> 05:36.200 a Web app or a mobile app might be a client or a desktop app or whatever it is. 05:37.370 --> 05:42.320 But this next section, I think, is to really take things to the next level for you. 05:42.410 --> 05:45.700 So without further ado, let's jump to the next section.