1 00:00:00,210 --> 00:00:06,270 OK, and once we're done with the postman before we start setting up our database, let's quickly talk 2 00:00:06,270 --> 00:00:10,470 about our roots more specifically why we use such structure. 3 00:00:10,920 --> 00:00:14,480 Long story short, it's because we're building a rest API. 4 00:00:15,120 --> 00:00:20,070 And since these days, the term API is used pretty much for everything, not just all. 5 00:00:20,070 --> 00:00:26,340 Agree that in our case, since we're building a server, essentially we want to create a HTP interface. 6 00:00:26,730 --> 00:00:32,280 So the other apps, most likely from the ones, can interact with our data. 7 00:00:32,729 --> 00:00:35,220 That's how we view API in this scenario. 8 00:00:35,730 --> 00:00:42,900 And when it comes to rest, it stands for representational state transfer and arguably the most popular 9 00:00:43,080 --> 00:00:44,630 API design pattern. 10 00:00:45,000 --> 00:00:53,580 And essentially it's a pattern that combines HTP verbs, route paths and our resources EQ data so effectively 11 00:00:54,030 --> 00:00:56,160 determines how the API looks like. 12 00:00:56,790 --> 00:00:58,140 Now let me emphasize something. 13 00:00:58,140 --> 00:01:02,490 It's a pattern, not a strictly enforced set of rules. 14 00:01:03,000 --> 00:01:07,720 So nothing stops you from setting your own API in a totally different manner. 15 00:01:08,130 --> 00:01:14,940 In fact, if you have used APIs on your front end apps, you know that some of them have a totally different 16 00:01:14,940 --> 00:01:15,450 structure. 17 00:01:15,890 --> 00:01:21,630 Has the best advice I can give you is this whatever pattern you decide on, stick with it, or in other 18 00:01:21,630 --> 00:01:22,660 words, be consistent. 19 00:01:23,040 --> 00:01:26,190 Otherwise, it's just going to be very confusing for your users. 20 00:01:26,550 --> 00:01:30,210 And this is a common approach where you have the main list. 21 00:01:30,690 --> 00:01:36,660 So that could be orders, that could be customers, that could be items, whatever. 22 00:01:36,690 --> 00:01:38,820 And of course, in our case, it is tasks. 23 00:01:39,000 --> 00:01:41,850 And in order to get all the items we go with, get method. 24 00:01:42,180 --> 00:01:46,950 And then if we want to create one, it's going to be the same end point. 25 00:01:47,190 --> 00:01:49,790 But we just go with a different method. 26 00:01:49,800 --> 00:01:54,110 And of course, in this case it is both and not to be redundant. 27 00:01:54,150 --> 00:02:00,330 We already discussed this before, but just because they have the same, you are all the same endpoint 28 00:02:00,660 --> 00:02:02,910 since the methods are different in this case. 29 00:02:02,910 --> 00:02:06,690 We have to get and of course in the second scenario we have post. 30 00:02:07,050 --> 00:02:10,770 These are two totally different requests. 31 00:02:11,009 --> 00:02:12,060 Please keep that in mind. 32 00:02:12,510 --> 00:02:17,010 And then for individual item, you have the same path pretty much. 33 00:02:17,310 --> 00:02:23,940 So you have API and then tasks or customers or whatever, and then you just use the primes to point 34 00:02:23,940 --> 00:02:25,650 to that one specific item. 35 00:02:25,920 --> 00:02:31,890 And then if you want to get the item and if it is a good method for update, you'll use put or patch 36 00:02:32,220 --> 00:02:36,390 and then to delete one, you'll use the delete method instead. 37 00:02:36,660 --> 00:02:43,530 And since JSON is a common format for receiving and sending data in, rest API will use of that approach 38 00:02:43,530 --> 00:02:43,880 as well. 39 00:02:43,890 --> 00:02:50,550 So even though at the moment we use some method in our out, eventually we'll switch to just one method 40 00:02:50,550 --> 00:02:51,090 instead. 41 00:02:51,570 --> 00:02:55,940 Also, I would like to point out that rest in general is somewhat fuzzy. 42 00:02:56,520 --> 00:03:03,690 In fact, oftentimes you'll deviate away from straight up rest since that's what the setup will require. 43 00:03:04,110 --> 00:03:04,980 One more thing. 44 00:03:04,980 --> 00:03:06,600 You can probably notice something. 45 00:03:06,930 --> 00:03:12,960 Essentially, our API allows our user to perform a covert operations on our data. 46 00:03:13,290 --> 00:03:17,730 And Krod stands for Create, Read, Update and Destroy. 47 00:03:18,060 --> 00:03:24,630 And it's a common approach where the API interface is built around groud since those are usually more 48 00:03:24,630 --> 00:03:32,280 typically operations that users or APS want to perform on a given data, whether it is a user's orders, 49 00:03:32,280 --> 00:03:38,790 customers or in our case, of course, it is going to be a task and will return to credibility later 50 00:03:39,030 --> 00:03:42,300 when I can actually show you how it relates to our data. 51 00:03:42,780 --> 00:03:49,110 Lastly, there's obviously more to arrest and some of that we will discuss in later project. 52 00:03:49,560 --> 00:03:55,620 But since I'm not a big fan of long slide videos, then I believe we covered all the major points. 53 00:03:55,980 --> 00:03:59,320 We'll stop right here and move on to our database set up.