1 00:00:00,578 --> 00:00:02,363 - [Instructor] Hi and welcome back to the course. 2 00:00:02,363 --> 00:00:05,087 In this video we're going to look at REST principles 3 00:00:05,087 --> 00:00:07,135 and this is really important. 4 00:00:07,135 --> 00:00:09,180 This lecture may be slightly confusing 5 00:00:09,180 --> 00:00:11,267 and it's slightly abstract, 6 00:00:11,267 --> 00:00:13,614 and please do ask questions at any point 7 00:00:13,614 --> 00:00:16,389 if you have any questions at all. 8 00:00:16,389 --> 00:00:20,087 Let's look at what we know now about HTTP. 9 00:00:20,087 --> 00:00:23,254 Going to a site performs a GET request 10 00:00:24,634 --> 00:00:26,379 and this normally returns HTML, 11 00:00:26,379 --> 00:00:28,123 but it may return other things, 12 00:00:28,123 --> 00:00:31,728 such as text for example or errors, 13 00:00:31,728 --> 00:00:34,159 and also we can do things other than GET. 14 00:00:34,159 --> 00:00:36,409 We can do POST for example. 15 00:00:37,710 --> 00:00:39,149 Okay, so this is what we know already. 16 00:00:39,149 --> 00:00:42,984 Now let's look at what a REST API is. 17 00:00:42,984 --> 00:00:46,852 A REST API uses those same concepts that we've looked at 18 00:00:46,852 --> 00:00:48,935 GET, POST, and so on 19 00:00:50,167 --> 00:00:53,621 so there's no technical things going on in a REST API. 20 00:00:53,621 --> 00:00:58,165 All that at REST API is or rather all that REST is 21 00:00:58,165 --> 00:00:59,666 is a way of thinking 22 00:00:59,666 --> 00:01:02,539 about how a web server responds to your requests 23 00:01:02,539 --> 00:01:05,872 and how a web server behaves in general. 24 00:01:07,876 --> 00:01:10,950 It doesn't respond with just data. 25 00:01:10,950 --> 00:01:13,912 It responds with something called resources. 26 00:01:13,912 --> 00:01:16,081 Now a resource is essentially just data, 27 00:01:16,081 --> 00:01:18,961 but it's a shift in the way of thinking. 28 00:01:18,961 --> 00:01:20,823 So we must stop thinking about 29 00:01:20,823 --> 00:01:22,427 we ask the server something 30 00:01:22,427 --> 00:01:24,259 and the server responds with data 31 00:01:24,259 --> 00:01:26,087 and now we have to start thinking about 32 00:01:26,087 --> 00:01:30,505 we are asking for a resource, for a thing in the server. 33 00:01:30,505 --> 00:01:32,477 It's very similar to object-oriented programming. 34 00:01:32,477 --> 00:01:35,679 So we can think of the server as having resources 35 00:01:35,679 --> 00:01:38,797 and each resource is able to interact 36 00:01:38,797 --> 00:01:40,332 with the pertinent request. 37 00:01:40,332 --> 00:01:44,645 We're going to look at what the pertinent request is now. 38 00:01:44,645 --> 00:01:47,645 So let's say we have this GET 39 00:01:49,463 --> 00:01:51,560 endpoint, our server has been programmed 40 00:01:51,560 --> 00:01:53,023 to be able to receive this 41 00:01:53,023 --> 00:01:56,576 GET request/item/chair. 42 00:01:56,576 --> 00:01:57,958 It also has been programmed to 43 00:01:57,958 --> 00:02:00,936 receive this POST request/item/chair 44 00:02:00,936 --> 00:02:02,606 with some extra data 45 00:02:02,606 --> 00:02:05,564 and such as to create a new chair for example. 46 00:02:05,564 --> 00:02:08,532 It also has been programmed to accept this request 47 00:02:08,532 --> 00:02:12,348 PUT/item/chair presumably also with some extra data 48 00:02:12,348 --> 00:02:15,068 so it can create or update the chair, 49 00:02:15,068 --> 00:02:18,902 and also it can deal with the DELETE/item/chair. 50 00:02:18,902 --> 00:02:22,058 As you can see all of these four requests 51 00:02:22,058 --> 00:02:25,607 have the same endpoint /item/chair. 52 00:02:25,607 --> 00:02:28,955 That's because they are all accessing the same resource. 53 00:02:28,955 --> 00:02:32,205 The chair element of the item resource. 54 00:02:33,693 --> 00:02:36,352 So this could be the item resource, 55 00:02:36,352 --> 00:02:38,483 and whenever we interact with an item 56 00:02:38,483 --> 00:02:41,941 we know that the endpoint is going to be the same. 57 00:02:41,941 --> 00:02:44,059 Now we can start thinking of 58 00:02:44,059 --> 00:02:45,951 our interactions with the server 59 00:02:45,951 --> 00:02:50,619 as not individual requests, but resources, 60 00:02:50,619 --> 00:02:53,220 and now we can do things like GET a resource 61 00:02:53,220 --> 00:02:54,869 or POST something to the resource 62 00:02:54,869 --> 00:02:58,336 or create a resource, delete a resource and so on. 63 00:02:58,336 --> 00:03:00,413 Which simplifies the way of thinking, 64 00:03:00,413 --> 00:03:03,916 simplifies the thought process behind these interactions, 65 00:03:03,916 --> 00:03:06,025 because now instead of dealing with just 66 00:03:06,025 --> 00:03:07,256 individual endpoints 67 00:03:07,256 --> 00:03:09,033 we're dealing with something a bit larger. 68 00:03:09,033 --> 00:03:11,977 So once again, similar to object-oriented programming. 69 00:03:11,977 --> 00:03:13,686 In object-oriented programming objects 70 00:03:13,686 --> 00:03:16,147 are just things that hold some data 71 00:03:16,147 --> 00:03:18,738 and then some more data in the form of methods 72 00:03:18,738 --> 00:03:19,870 and they have a name 73 00:03:19,870 --> 00:03:23,414 and here it's really a similar thing. 74 00:03:23,414 --> 00:03:26,756 Another endpoint may be GET/items, 75 00:03:26,756 --> 00:03:28,885 and that we can probably see the similarity. 76 00:03:28,885 --> 00:03:31,846 Items and item probably fairly related, 77 00:03:31,846 --> 00:03:33,986 but it's a different endpoint 78 00:03:33,986 --> 00:03:37,576 and we're no longer retrieving an individual resource, 79 00:03:37,576 --> 00:03:41,245 /items probably means we're retrieving multiple items, 80 00:03:41,245 --> 00:03:43,615 therefore, it cannot be the item resource. 81 00:03:43,615 --> 00:03:47,823 It must be something like an item list resource for example. 82 00:03:47,823 --> 00:03:52,266 In this section we're going to look at creating these too 83 00:03:52,266 --> 00:03:54,214 programmatically. 84 00:03:54,214 --> 00:03:56,361 Another key feature of REST 85 00:03:56,361 --> 00:03:58,869 is that it is stateless 86 00:03:58,869 --> 00:04:01,471 or it is supposed to be stateless. 87 00:04:01,471 --> 00:04:04,845 Now stateless is always really confusing initially. 88 00:04:04,845 --> 00:04:07,078 But all that it means is that one request 89 00:04:07,078 --> 00:04:10,901 cannot depend on any other requests. 90 00:04:10,901 --> 00:04:12,398 And again this may be confusing. 91 00:04:12,398 --> 00:04:15,776 As we programme this will make more sense. 92 00:04:15,776 --> 00:04:19,547 So the server only knows about the current request 93 00:04:19,547 --> 00:04:21,876 and not about any previous requests. 94 00:04:21,876 --> 00:04:23,630 Let me give you a couple examples. 95 00:04:23,630 --> 00:04:27,308 For our first example image we create a 96 00:04:27,308 --> 00:04:28,761 chair item. 97 00:04:28,761 --> 00:04:32,637 We create a request that is POST/item/chair 98 00:04:32,637 --> 00:04:35,637 and presumably that creates a chair. 99 00:04:36,669 --> 00:04:39,087 The server doesn't know the item now exists. 100 00:04:39,087 --> 00:04:42,632 It has created it, it has put it in a database, 101 00:04:42,632 --> 00:04:44,854 and then its forgot about it because its 102 00:04:44,854 --> 00:04:46,436 sent us a response back, it said 103 00:04:46,436 --> 00:04:48,435 item created for example, 104 00:04:48,435 --> 00:04:50,849 and then it's forgotten that the items exists, 105 00:04:50,849 --> 00:04:53,617 but it is in the database. 106 00:04:53,617 --> 00:04:57,243 When we do GET/item/chair 107 00:04:57,243 --> 00:05:00,426 the server cannot say okay this exists. 108 00:05:00,426 --> 00:05:02,079 It has to go to the database, 109 00:05:02,079 --> 00:05:03,788 check to see if it exists, 110 00:05:03,788 --> 00:05:05,668 and then return the item to us 111 00:05:05,668 --> 00:05:08,884 if it does exist or an error otherwise. 112 00:05:08,884 --> 00:05:11,995 So as you can see this sort of makes sense, 113 00:05:11,995 --> 00:05:15,523 but the server doesn't know that the item exists 114 00:05:15,523 --> 00:05:17,897 it has to do the full check, 115 00:05:17,897 --> 00:05:21,152 go to the database and check it. 116 00:05:21,152 --> 00:05:22,267 So to GET an item 117 00:05:22,267 --> 00:05:24,992 you don't have to have created the item before. 118 00:05:24,992 --> 00:05:26,683 We could just do the GET request 119 00:05:26,683 --> 00:05:28,662 and then that would go to the database 120 00:05:28,662 --> 00:05:30,102 and see if the item is there. 121 00:05:30,102 --> 00:05:32,596 So it doesn't require the POST request 122 00:05:32,596 --> 00:05:35,347 to have happened before. 123 00:05:35,347 --> 00:05:38,517 Okay, so this is one example here's another example 124 00:05:38,517 --> 00:05:41,159 that is going to be really useful this section. 125 00:05:41,159 --> 00:05:45,326 Say a user logs into a web application, for example Twitter. 126 00:05:47,528 --> 00:05:50,867 When we do that the server responds with some data 127 00:05:50,867 --> 00:05:52,895 and that data is going to be really important. 128 00:05:52,895 --> 00:05:56,207 That data is going to be unique to this user. 129 00:05:56,207 --> 00:05:58,026 And once it does that the server doesn't know 130 00:05:58,026 --> 00:06:01,390 the user is logged in since it doesn't have any state. 131 00:06:01,390 --> 00:06:03,966 So what do we do? 132 00:06:03,966 --> 00:06:06,978 Well remember that piece of unique data 133 00:06:06,978 --> 00:06:09,803 the server returned when we logged in? 134 00:06:09,803 --> 00:06:12,617 The web application has to send that data 135 00:06:12,617 --> 00:06:14,948 every time it interacts with a server 136 00:06:14,948 --> 00:06:16,281 so that the server can see 137 00:06:16,281 --> 00:06:19,207 okay I sent this data earlier, 138 00:06:19,207 --> 00:06:21,846 this user is indeed logged in, 139 00:06:21,846 --> 00:06:24,220 because the data is unique. 140 00:06:24,220 --> 00:06:27,271 And that data had to be sent in every request 141 00:06:27,271 --> 00:06:29,234 or else the server won't be able to associate 142 00:06:29,234 --> 00:06:31,401 the request with the user. 143 00:06:32,462 --> 00:06:35,255 This authentication we're going to implement in this section 144 00:06:35,255 --> 00:06:37,119 and everything is going to make a lot more sense. 145 00:06:37,119 --> 00:06:38,800 So if this is confusing 146 00:06:38,800 --> 00:06:41,289 don't worry because it is always confusing initially. 147 00:06:41,289 --> 00:06:43,217 The first time I learned about REST 148 00:06:43,217 --> 00:06:45,231 I though what the hell is stateless 149 00:06:45,231 --> 00:06:49,085 and it didn't really make sense for a long time. 150 00:06:49,085 --> 00:06:52,337 So don't worry if it is confusing. 151 00:06:52,337 --> 00:06:54,338 As I said as we programme the APIs 152 00:06:54,338 --> 00:06:57,059 a lot of these things will make sense, 153 00:06:57,059 --> 00:06:59,689 because they just do 154 00:06:59,689 --> 00:07:02,677 so they'll come naturally to you, 155 00:07:02,677 --> 00:07:05,660 and always ask questions at anytime 156 00:07:05,660 --> 00:07:07,891 and I'm always available to help and guide you 157 00:07:07,891 --> 00:07:10,053 personally if you need anything. 158 00:07:10,053 --> 00:07:12,109 So don't doubt, go to the course Q&A 159 00:07:12,109 --> 00:07:16,214 and ask questions away if you need anything. 160 00:07:16,214 --> 00:07:18,772 So that's everything for this video we've looked at REST 161 00:07:18,772 --> 00:07:20,705 and what it means and essentially it means 162 00:07:20,705 --> 00:07:23,021 that we are now dealing with resources 163 00:07:23,021 --> 00:07:25,405 and we're dealing with 164 00:07:25,405 --> 00:07:27,973 stateless servers. 165 00:07:27,973 --> 00:07:31,440 So we're going to implement a REST API in this section. 166 00:07:31,440 --> 00:07:33,002 So I hope you enjoy that 167 00:07:33,002 --> 00:07:34,258 and that's it for this video 168 00:07:34,258 --> 00:07:36,925 so I'll see you on the next one.