1 00:00:01,670 --> 00:00:04,320 ‫So now that we know what Express is, 2 00:00:04,320 --> 00:00:07,550 ‫we're almost ready to start building our API. 3 00:00:07,550 --> 00:00:08,890 ‫But before we do that, 4 00:00:08,890 --> 00:00:12,300 ‫I need to quickly talk about APIs on a higher level, 5 00:00:12,300 --> 00:00:13,910 ‫and more importantly, 6 00:00:13,910 --> 00:00:16,370 ‫introduce you to the REST Architecture 7 00:00:16,370 --> 00:00:19,640 ‫which is the most used API architecture today. 8 00:00:19,640 --> 00:00:23,270 ‫This way, we will actually know what we're building. 9 00:00:23,270 --> 00:00:25,710 ‫So it's extremely important to understand the stuff 10 00:00:25,710 --> 00:00:27,860 ‫in this video before moving on, 11 00:00:27,860 --> 00:00:30,580 ‫so that we actually know what we're building 12 00:00:30,580 --> 00:00:32,603 ‫throughout the rest of the course. 13 00:00:33,630 --> 00:00:34,890 ‫First of all, 14 00:00:34,890 --> 00:00:38,390 ‫API stands for Application Programming Interface 15 00:00:38,390 --> 00:00:40,130 ‫and on a very high level, 16 00:00:40,130 --> 00:00:43,150 ‫it's basically a piece of software that can be used 17 00:00:43,150 --> 00:00:45,270 ‫by another piece of software 18 00:00:45,270 --> 00:00:48,213 ‫in order to allow applications to talk to each other. 19 00:00:49,080 --> 00:00:51,420 ‫We have actually talked about APIs before, 20 00:00:51,420 --> 00:00:53,780 ‫more specifically, web APIs, 21 00:00:53,780 --> 00:00:56,300 ‫where we simply built an app that sends data 22 00:00:56,300 --> 00:00:59,640 ‫to a client whenever a request comes in. 23 00:00:59,640 --> 00:01:02,530 ‫Imagine we have our app running on a server 24 00:01:02,530 --> 00:01:04,060 ‫and we have a client. 25 00:01:04,060 --> 00:01:08,020 ‫So in fact, we effectively have two pieces of software 26 00:01:08,020 --> 00:01:10,250 ‫talking to each other, right? 27 00:01:10,250 --> 00:01:13,550 ‫And this is the kind of API we will build in this course. 28 00:01:13,550 --> 00:01:17,470 ‫And I guess it's the most widely used type of API out there. 29 00:01:17,470 --> 00:01:21,970 ‫But in fact, APIs aren't only used to send data, 30 00:01:21,970 --> 00:01:25,493 ‫and aren't always related to web development or JavaScript. 31 00:01:26,400 --> 00:01:29,500 ‫The application in API can actually mean 32 00:01:29,500 --> 00:01:32,710 ‫many different things as long as the piece of software 33 00:01:32,710 --> 00:01:35,050 ‫is relatively stand alone. 34 00:01:35,050 --> 00:01:35,900 ‫Take for example, 35 00:01:35,900 --> 00:01:38,870 ‫the Node File System, or the HTTP Modules. 36 00:01:38,870 --> 00:01:42,010 ‫We can say that they are small pieces of software 37 00:01:42,010 --> 00:01:43,110 ‫and we can use them, 38 00:01:43,110 --> 00:01:46,970 ‫we can interact with them by using their API. 39 00:01:46,970 --> 00:01:47,803 ‫For example, 40 00:01:47,803 --> 00:01:51,150 ‫when we use the readfile function from the FS Module, 41 00:01:51,150 --> 00:01:54,020 ‫we are actually using the FS API. 42 00:01:54,020 --> 00:01:57,380 ‫And that's why you will sometimes hear the term node APIs. 43 00:01:57,380 --> 00:02:01,090 ‫And that usually simply refers to the core node modules 44 00:02:01,090 --> 00:02:02,920 ‫that we can interact with. 45 00:02:02,920 --> 00:02:05,670 ‫Or when we do DOM manipulation in the browser, 46 00:02:05,670 --> 00:02:08,650 ‫we are not really using the JavaScript language itself, 47 00:02:08,650 --> 00:02:12,440 ‫but rather, the DOM API that the browser exposes to us, 48 00:02:12,440 --> 00:02:14,280 ‫so it gives us access to it. 49 00:02:14,280 --> 00:02:15,930 ‫Or even another example, 50 00:02:15,930 --> 00:02:19,080 ‫let's say we create a class in any programming language 51 00:02:19,080 --> 00:02:21,940 ‫like Java and then add some public methods 52 00:02:21,940 --> 00:02:23,420 ‫or properties to it. 53 00:02:23,420 --> 00:02:26,860 ‫These methods will then be the API of each object 54 00:02:26,860 --> 00:02:29,450 ‫created from that class because we're giving 55 00:02:29,450 --> 00:02:31,890 ‫other pieces of software the possibility 56 00:02:31,890 --> 00:02:35,420 ‫of interacting with our initial piece of software, 57 00:02:35,420 --> 00:02:37,278 ‫the objects, in this case. 58 00:02:37,278 --> 00:02:40,810 ‫You see, API has actually a broader meaning 59 00:02:40,810 --> 00:02:42,810 ‫than just building web APIs. 60 00:02:42,810 --> 00:02:47,420 ‫Alright? Anyway, a web API is what's most important 61 00:02:47,420 --> 00:02:50,340 ‫for us in the context of note. 62 00:02:50,340 --> 00:02:53,050 ‫Let's now take a look at the REST Architecture 63 00:02:53,050 --> 00:02:54,203 ‫to build APIs. 64 00:02:55,820 --> 00:02:59,910 ‫REST, which stands for Representational States Transfer, 65 00:02:59,910 --> 00:03:03,930 ‫is basically a way of building web APIs in a logical way, 66 00:03:03,930 --> 00:03:06,060 ‫making them easy to consume 67 00:03:06,060 --> 00:03:09,420 ‫because remember, we build an API for ourselves 68 00:03:09,420 --> 00:03:12,023 ‫or for others to consume, okay? 69 00:03:12,023 --> 00:03:15,640 ‫We want to make the process of actually using the API 70 00:03:15,640 --> 00:03:17,633 ‫as smooth as possible for the user. 71 00:03:18,490 --> 00:03:20,830 ‫Now, to build RESTful APIs, 72 00:03:20,830 --> 00:03:24,180 ‫which means APIs following the REST Architecture, 73 00:03:24,180 --> 00:03:26,660 ‫we just need to follow a couple of principles. 74 00:03:26,660 --> 00:03:31,240 ‫First, we need to separate our API into logical resources. 75 00:03:31,240 --> 00:03:33,860 ‫These resources should then be exposed, 76 00:03:33,860 --> 00:03:35,900 ‫which means to be made available 77 00:03:35,900 --> 00:03:39,420 ‫using structured, resource-based URLs. 78 00:03:39,420 --> 00:03:41,460 ‫To perform different actions on data 79 00:03:41,460 --> 00:03:44,677 ‫like reading or creating or deleting data, 80 00:03:44,677 --> 00:03:49,677 ‫the API should use the right HTP methods and not the URL. 81 00:03:50,270 --> 00:03:53,210 ‫Now, the data that we actually send back to the client 82 00:03:53,210 --> 00:03:55,420 ‫or that we received from the client 83 00:03:55,420 --> 00:03:58,030 ‫should usually use the JSON data format, 84 00:03:58,030 --> 00:04:01,010 ‫where some formatting standard applied to it. 85 00:04:01,010 --> 00:04:04,500 ‫Finally, another important principle of REST APIs 86 00:04:04,500 --> 00:04:07,560 ‫is that they must be stateless. 87 00:04:07,560 --> 00:04:09,950 ‫So this is a very broad overview. 88 00:04:09,950 --> 00:04:12,030 ‫Let's now start talking about these principles 89 00:04:12,030 --> 00:04:15,310 ‫one-by-one starting with resources 90 00:04:15,310 --> 00:04:17,810 ‫and using the Nators API that we're gonna build 91 00:04:17,810 --> 00:04:19,803 ‫in this course as an example here. 92 00:04:20,960 --> 00:04:24,910 ‫The key abstraction of information in REST is a resource, 93 00:04:24,910 --> 00:04:27,450 ‫and therefore all the data that we wanna share 94 00:04:27,450 --> 00:04:32,040 ‫in the API should be divided into logical resources. 95 00:04:32,040 --> 00:04:34,350 ‫Now, what actually is a resource? 96 00:04:34,350 --> 00:04:36,380 ‫Well, in the context of REST, 97 00:04:36,380 --> 00:04:39,520 ‫it is an object or a representation of something 98 00:04:39,520 --> 00:04:42,020 ‫which has some data associated to it. 99 00:04:42,020 --> 00:04:42,853 ‫For example, 100 00:04:42,853 --> 00:04:45,570 ‫tours, or users, or reviews in the case 101 00:04:45,570 --> 00:04:48,020 ‫of the example that we are following. 102 00:04:48,020 --> 00:04:50,730 ‫So basically, any information that can be named 103 00:04:50,730 --> 00:04:53,040 ‫can be a resource, alright? 104 00:04:53,040 --> 00:04:56,050 ‫It just has to be a name, though, not a verb. 105 00:04:56,050 --> 00:04:57,690 ‫Now, we need to expose, 106 00:04:57,690 --> 00:04:59,480 ‫which means to make available, 107 00:04:59,480 --> 00:05:02,520 ‫the data using some structured URLs 108 00:05:02,520 --> 00:05:04,890 ‫that the client can send a request to. 109 00:05:04,890 --> 00:05:07,611 ‫For example, something like this. 110 00:05:07,611 --> 00:05:10,740 ‫This entire address is called the URL 111 00:05:10,740 --> 00:05:14,323 ‫and this /addNewTour is called an API Endpoint. 112 00:05:15,269 --> 00:05:17,840 ‫Our API will have many different endpoints 113 00:05:17,840 --> 00:05:20,560 ‫just like this fictional endpoints that I have here, 114 00:05:20,560 --> 00:05:23,730 ‫each of which will send different data back to the client 115 00:05:23,730 --> 00:05:26,150 ‫or also perform different actions. 116 00:05:26,150 --> 00:05:28,440 ‫Now, there's actually something very wrong 117 00:05:28,440 --> 00:05:31,750 ‫with these endpoints here because they really don't follow 118 00:05:31,750 --> 00:05:34,827 ‫the third rule which says that we should only use 119 00:05:34,827 --> 00:05:39,110 ‫the HTTP methods in order to perform actions on data. 120 00:05:39,110 --> 00:05:42,360 ‫So, endpoints should only contain our resources 121 00:05:42,360 --> 00:05:45,070 ‫and not the actions that can be performed on them 122 00:05:45,070 --> 00:05:48,313 ‫because they will quickly become a nightmare to maintain. 123 00:05:49,644 --> 00:05:54,210 ‫How should we use these HTTP methods in practice? 124 00:05:54,210 --> 00:05:56,120 ‫Well, let's see how these endpoints 125 00:05:56,120 --> 00:05:59,620 ‫should actually look like starting with /getTour. 126 00:05:59,620 --> 00:06:03,290 ‫So this /getTour endpoint is to get data about a tour. 127 00:06:03,290 --> 00:06:06,240 ‫And so we should simply name the endpoint /tours 128 00:06:06,240 --> 00:06:08,740 ‫and send the data whenever a get request 129 00:06:08,740 --> 00:06:10,430 ‫is made to this endpoint. 130 00:06:10,430 --> 00:06:11,650 ‫So in other words, 131 00:06:11,650 --> 00:06:14,730 ‫when a client uses a GET HTTP method 132 00:06:14,730 --> 00:06:16,700 ‫to access the endpoint. 133 00:06:16,700 --> 00:06:17,870 ‫And just like this, 134 00:06:17,870 --> 00:06:20,220 ‫we only have resources in the endpoint 135 00:06:20,220 --> 00:06:23,670 ‫or in the URL and no verbs because the verb 136 00:06:23,670 --> 00:06:26,870 ‫is now in the HTTP method, right? 137 00:06:26,870 --> 00:06:27,703 ‫And by the way, 138 00:06:27,703 --> 00:06:30,490 ‫it's a common practice to always use the resource name 139 00:06:30,490 --> 00:06:34,820 ‫in plural which is why I have /tours here and not /tour. 140 00:06:34,820 --> 00:06:37,790 ‫Now, the convention is that when calling that endpoint, 141 00:06:37,790 --> 00:06:41,820 ‫we get back all the tours that are in a database, okay? 142 00:06:41,820 --> 00:06:44,820 ‫But if we only want the tour with one I.D., 143 00:06:44,820 --> 00:06:48,960 ‫let's say seven, we add that seven after another slash 144 00:06:48,960 --> 00:06:50,580 ‫or in a search query. 145 00:06:50,580 --> 00:06:53,490 ‫Or it could also be the name of a tour instead of the I.D., 146 00:06:53,490 --> 00:06:55,410 ‫or some other unique identifier. 147 00:06:55,410 --> 00:06:58,300 ‫The detail doesn't really matter at this point, alright? 148 00:06:58,300 --> 00:07:01,180 ‫Later, I will show you how easy it is to actually implement 149 00:07:01,180 --> 00:07:03,410 ‫this kind of logic with Express 150 00:07:03,410 --> 00:07:06,733 ‫because this is actually where Express really shines. 151 00:07:07,606 --> 00:07:10,460 ‫The first HTTP method or verb 152 00:07:10,460 --> 00:07:12,530 ‫that we can respond to is GET 153 00:07:12,530 --> 00:07:16,290 ‫and it's used to perform the Read operation on data. 154 00:07:16,290 --> 00:07:18,290 ‫Next stop, if the client wants 155 00:07:18,290 --> 00:07:21,450 ‫to create a new resource in our database, 156 00:07:21,450 --> 00:07:23,200 ‫in this example, a new tour, 157 00:07:23,200 --> 00:07:25,510 ‫the POST method should be used. 158 00:07:25,510 --> 00:07:28,490 ‫So we learned earlier that a POST request can be used 159 00:07:28,490 --> 00:07:30,230 ‫to send data to the server, 160 00:07:30,230 --> 00:07:32,270 ‫and so it makes sense to use POST 161 00:07:32,270 --> 00:07:35,530 ‫in order to create new resources, right? 162 00:07:35,530 --> 00:07:38,530 ‫Now in this case, usually no I.D. will be sent 163 00:07:38,530 --> 00:07:40,860 ‫because the server should automatically figure out 164 00:07:40,860 --> 00:07:42,948 ‫the I.D. for the new resource. 165 00:07:42,948 --> 00:07:46,090 ‫Anyway, what's really important to note here 166 00:07:46,090 --> 00:07:50,289 ‫is how the endpoint name is the exact same name as before. 167 00:07:50,289 --> 00:07:53,870 ‫The only difference is really the HTP method 168 00:07:53,870 --> 00:07:55,960 ‫that is used for the request. 169 00:07:55,960 --> 00:07:59,410 ‫If the /tours endpoint is accessed with GET, 170 00:07:59,410 --> 00:08:01,460 ‫we send data to the client. 171 00:08:01,460 --> 00:08:04,060 ‫But if the same endpoint is accessed with POST, 172 00:08:04,060 --> 00:08:06,550 ‫we expect data to come in with a request, 173 00:08:06,550 --> 00:08:08,760 ‫so that we can then create a new resource 174 00:08:08,760 --> 00:08:10,330 ‫on the server side. 175 00:08:10,330 --> 00:08:14,460 ‫So that is really the beauty of only using HTTP methods 176 00:08:14,460 --> 00:08:17,480 ‫rather than messing with verbs in endpoint names. 177 00:08:17,480 --> 00:08:21,210 ‫Again, it would really become unmanageable very quick. 178 00:08:21,210 --> 00:08:23,620 ‫Alright, next, there should also be 179 00:08:23,620 --> 00:08:26,390 ‫the ability to update resources. 180 00:08:26,390 --> 00:08:27,310 ‫And for that, 181 00:08:27,310 --> 00:08:29,550 ‫either a PUT or a PATCH request 182 00:08:29,550 --> 00:08:31,550 ‫should be made to the endpoint. 183 00:08:31,550 --> 00:08:33,750 ‫The difference between them is that with PUT, 184 00:08:33,750 --> 00:08:37,280 ‫the client is supposed to send the entire updated object, 185 00:08:37,280 --> 00:08:38,370 ‫while with PATCH, 186 00:08:38,370 --> 00:08:40,967 ‫it is supposed to send only the part of the object 187 00:08:40,967 --> 00:08:43,060 ‫that has been changed. 188 00:08:43,060 --> 00:08:45,140 ‫But both of them have the ability 189 00:08:45,140 --> 00:08:46,750 ‫to send data to the server. 190 00:08:46,750 --> 00:08:50,750 ‫A bit like POST, actually, but with a different intent. 191 00:08:50,750 --> 00:08:53,070 ‫So POST is to create a new resource, 192 00:08:53,070 --> 00:08:55,370 ‫while PUT or PATCH are used 193 00:08:55,370 --> 00:08:57,500 ‫to update an existing resource 194 00:08:57,500 --> 00:08:59,660 ‫and so it then makes all the difference. 195 00:08:59,660 --> 00:09:02,110 ‫And finally, to the litter resource, 196 00:09:02,110 --> 00:09:05,110 ‫there is the DELETE HTTP method. 197 00:09:05,110 --> 00:09:08,010 ‫Again, the I.D. or some other unique identifier 198 00:09:08,010 --> 00:09:10,120 ‫of the resource to be deleted 199 00:09:10,120 --> 00:09:11,820 ‫should be part of the URL. 200 00:09:11,820 --> 00:09:14,560 ‫Now, usually, in order to actually be able 201 00:09:14,560 --> 00:09:16,610 ‫to perform this kind of request, 202 00:09:16,610 --> 00:09:18,620 ‫the client must be authenticated. 203 00:09:18,620 --> 00:09:21,670 ‫So basically, log into your app, okay? 204 00:09:21,670 --> 00:09:24,349 ‫But that is, of course, a topic for much later. 205 00:09:24,349 --> 00:09:27,080 ‫So these are the five HTTP methods 206 00:09:27,080 --> 00:09:29,320 ‫that we can and should respond to 207 00:09:29,320 --> 00:09:31,570 ‫when building our RESTful APIs 208 00:09:31,570 --> 00:09:33,270 ‫so that the client can perform 209 00:09:33,270 --> 00:09:36,290 ‫the four basic CRUD operations. 210 00:09:36,290 --> 00:09:40,730 ‫So CRUD stands for Create, Read, Update and Delete. 211 00:09:40,730 --> 00:09:42,590 ‫And you will see this term all the time 212 00:09:42,590 --> 00:09:45,200 ‫related to APIs and database stuff. 213 00:09:45,200 --> 00:09:47,490 ‫And you see that these HTTP methods 214 00:09:47,490 --> 00:09:51,330 ‫map quite nicely to the basic CRUD operations. 215 00:09:51,330 --> 00:09:54,410 ‫Now, there might be actions that are not CRUD, 216 00:09:54,410 --> 00:09:55,460 ‫and in that case, 217 00:09:55,460 --> 00:09:58,120 ‫we just need to get creative with our inputs. 218 00:09:58,120 --> 00:09:58,953 ‫For example, 219 00:09:58,953 --> 00:10:01,010 ‫a log in or a search operation, 220 00:10:01,010 --> 00:10:04,361 ‫these are not really related to a particular resource 221 00:10:04,361 --> 00:10:06,630 ‫and they're not CRUD operations either, 222 00:10:06,630 --> 00:10:09,240 ‫but we still can create endpoints for them. 223 00:10:09,240 --> 00:10:12,530 ‫For example, like /login or /search. 224 00:10:12,530 --> 00:10:16,350 ‫But we'll talk more about these cases later in practice. 225 00:10:16,350 --> 00:10:18,290 ‫And just to finish this part now, 226 00:10:18,290 --> 00:10:21,330 ‫remember that we had two other crazy endpoint names 227 00:10:21,330 --> 00:10:23,870 ‫in the last slide which kind of involved 228 00:10:23,870 --> 00:10:26,780 ‫two resources at the same time, right? 229 00:10:26,780 --> 00:10:29,888 ‫And that's also no problem at all with REST. 230 00:10:29,888 --> 00:10:33,810 ‫So, /getToursByUser can simply be translated 231 00:10:33,810 --> 00:10:36,210 ‫to /users/tours, 232 00:10:36,210 --> 00:10:38,440 ‫in this case, user number three. 233 00:10:38,440 --> 00:10:40,200 ‫So this particular endpoint here 234 00:10:40,200 --> 00:10:42,340 ‫could send data about all the tours 235 00:10:42,340 --> 00:10:44,580 ‫that user number three has booked. 236 00:10:44,580 --> 00:10:45,519 ‫Makes sense? 237 00:10:45,519 --> 00:10:47,470 ‫Or in the case of deleting, 238 00:10:47,470 --> 00:10:50,170 ‫there could be a delete request to the same 239 00:10:50,170 --> 00:10:51,910 ‫or a very similar endpoint, 240 00:10:51,910 --> 00:10:54,440 ‫requesting tour number nine to be deleted 241 00:10:54,440 --> 00:10:57,330 ‫from user number three, okay? 242 00:10:57,330 --> 00:11:00,160 ‫So there really are a tons of possibilities 243 00:11:00,160 --> 00:11:02,470 ‫of combining resources like this. 244 00:11:02,470 --> 00:11:04,260 ‫But of course, we don't have to implement 245 00:11:04,260 --> 00:11:06,600 ‫all these combinations in our API. 246 00:11:06,600 --> 00:11:08,400 ‫We only implement what makes sense 247 00:11:08,400 --> 00:11:10,090 ‫in the case of our application 248 00:11:10,090 --> 00:11:13,203 ‫and the client that wants to consume our API. 249 00:11:13,203 --> 00:11:17,480 ‫So, this is how we make use of HTTP methods 250 00:11:17,480 --> 00:11:20,823 ‫to build user-friendly and nicely structured URLs 251 00:11:20,823 --> 00:11:24,145 ‫that are easy and logical to consume for the client. 252 00:11:24,145 --> 00:11:27,800 ‫Now, about the data that the client actually receives, 253 00:11:27,800 --> 00:11:30,610 ‫or that the server receives from the client, 254 00:11:30,610 --> 00:11:33,203 ‫usually, we use the JSON Data Format. 255 00:11:34,440 --> 00:11:37,400 ‫And so let's briefly learn what JSON actually is 256 00:11:37,400 --> 00:11:39,530 ‫and how to format our API responses. 257 00:11:39,530 --> 00:11:43,780 ‫JSON is a very lightweight data interchange format 258 00:11:43,780 --> 00:11:46,220 ‫which is heavily used by web APIs 259 00:11:46,220 --> 00:11:48,160 ‫coded in any programming language. 260 00:11:48,160 --> 00:11:50,740 ‫So it's just not related to a JavaScript. 261 00:11:50,740 --> 00:11:52,620 ‫And it's so widely used today 262 00:11:52,620 --> 00:11:55,930 ‫because it's really easy for both humans and computers 263 00:11:55,930 --> 00:11:57,990 ‫to understand and write JSON. 264 00:11:57,990 --> 00:12:00,510 ‫So you're probably already noticing that JSON 265 00:12:00,510 --> 00:12:04,020 ‫looks a bit like a regular JavaScript object, right? 266 00:12:04,020 --> 00:12:06,470 ‫With all these key-value pairs. 267 00:12:06,470 --> 00:12:08,320 ‫There are, however, some differences, 268 00:12:08,320 --> 00:12:10,960 ‫and the most important one is that all the keys 269 00:12:10,960 --> 00:12:12,580 ‫have to be strings. 270 00:12:12,580 --> 00:12:14,730 ‫It's also very typical for the values 271 00:12:14,730 --> 00:12:17,440 ‫to be strings as well but they can be other things 272 00:12:17,440 --> 00:12:20,690 ‫like numbers, true or false values, other object, 273 00:12:20,690 --> 00:12:23,328 ‫or even arrays of other values. 274 00:12:23,328 --> 00:12:25,790 ‫It's quite straighforward, actually. 275 00:12:25,790 --> 00:12:27,070 ‫And from this example, 276 00:12:27,070 --> 00:12:30,883 ‫you can kind of see how some typical JSON might look like. 277 00:12:31,890 --> 00:12:35,290 ‫Let's say that this is a data that we have in our database 278 00:12:35,290 --> 00:12:38,560 ‫for a GET request to this URL 279 00:12:38,560 --> 00:12:41,440 ‫so the tour with I.D. of five. 280 00:12:41,440 --> 00:12:44,300 ‫Now, we could send it back like this to the client, 281 00:12:44,300 --> 00:12:47,130 ‫but we usually do some simple response formatting 282 00:12:47,130 --> 00:12:48,620 ‫before sending. 283 00:12:48,620 --> 00:12:50,880 ‫There are a couple of standards for this 284 00:12:50,880 --> 00:12:54,570 ‫and we're gonna use a very simple one called Jsend. 285 00:12:54,570 --> 00:12:56,320 ‫We simply create a new object, 286 00:12:56,320 --> 00:12:58,310 ‫then add a status message to it 287 00:12:58,310 --> 00:13:00,740 ‫in order to inform the client whether the request 288 00:13:00,740 --> 00:13:03,350 ‫was a success, fail or error, 289 00:13:03,350 --> 00:13:05,390 ‫and then we put our original data 290 00:13:05,390 --> 00:13:08,510 ‫into a new object called Data, okay? 291 00:13:08,510 --> 00:13:10,640 ‫And we can develop this even a bit further 292 00:13:10,640 --> 00:13:12,020 ‫but this is really the simplest way 293 00:13:12,020 --> 00:13:14,250 ‫of formatting with Jsend. 294 00:13:14,250 --> 00:13:15,240 ‫And just, by the way, 295 00:13:15,240 --> 00:13:17,550 ‫wrapping the data into an additional object 296 00:13:17,550 --> 00:13:19,860 ‫like we did here is called Enveloping, 297 00:13:19,860 --> 00:13:21,470 ‫and it's a common practice 298 00:13:21,470 --> 00:13:25,550 ‫to mitigate some security issues and other problems. 299 00:13:25,550 --> 00:13:27,200 ‫Also, there are other standards 300 00:13:27,200 --> 00:13:30,330 ‫for response-formatting that you can look into, 301 00:13:30,330 --> 00:13:34,333 ‫like Jsend:API or the Odata JSON Protocol. 302 00:13:35,800 --> 00:13:37,470 ‫Alright, and finally, 303 00:13:37,470 --> 00:13:40,720 ‫a RESTful API should always be stateless. 304 00:13:40,720 --> 00:13:43,170 ‫So, what does stateless actually mean? 305 00:13:43,170 --> 00:13:45,960 ‫Well, in a stateless RESTful API, 306 00:13:45,960 --> 00:13:48,410 ‫all state is handled on the client 307 00:13:48,410 --> 00:13:50,120 ‫and not on the server. 308 00:13:50,120 --> 00:13:52,910 ‫And state simply refers to a piece of data 309 00:13:52,910 --> 00:13:55,750 ‫in the application that might change over time. 310 00:13:55,750 --> 00:13:56,583 ‫For example, 311 00:13:56,583 --> 00:13:58,720 ‫whether a certain user is logged in 312 00:13:58,720 --> 00:14:02,230 ‫or on a page with a list with several pages, 313 00:14:02,230 --> 00:14:04,150 ‫what the current page is. 314 00:14:04,150 --> 00:14:06,170 ‫Now the fact that the state should be handled 315 00:14:06,170 --> 00:14:09,910 ‫on the client means that each request must contain 316 00:14:09,910 --> 00:14:12,710 ‫all the information that is necessary to process 317 00:14:12,710 --> 00:14:15,780 ‫a certain request on the server, alright? 318 00:14:15,780 --> 00:14:17,170 ‫Does that make sense? 319 00:14:17,170 --> 00:14:21,030 ‫So, the server should never ever have to remember 320 00:14:21,030 --> 00:14:24,010 ‫the previous request in order to process 321 00:14:24,010 --> 00:14:25,906 ‫the current request. 322 00:14:25,906 --> 00:14:29,670 ‫Let's take the list with several pages as an example. 323 00:14:29,670 --> 00:14:32,980 ‫And let's say that recurrently on page five 324 00:14:32,980 --> 00:14:36,006 ‫and want to move forward to page six. 325 00:14:36,006 --> 00:14:39,710 ‫So we could have a simple endpoint called /tours/nextPage 326 00:14:40,650 --> 00:14:43,400 ‫and submit a request to it, right? 327 00:14:43,400 --> 00:14:45,610 ‫But the server would then have to figure out 328 00:14:45,610 --> 00:14:48,450 ‫what the current page is and based on that 329 00:14:48,450 --> 00:14:50,496 ‫send the next page to the client. 330 00:14:50,496 --> 00:14:51,730 ‫In other words, 331 00:14:51,730 --> 00:14:54,950 ‫the server would have to remember the previous request. 332 00:14:54,950 --> 00:14:57,640 ‫It would have to handle the state server side 333 00:14:57,640 --> 00:15:00,260 ‫and that is exactly what we want to avoid 334 00:15:00,260 --> 00:15:03,120 ‫in RESTful APIs, okay? 335 00:15:03,120 --> 00:15:04,630 ‫Instead, in this case, 336 00:15:04,630 --> 00:15:07,550 ‫we should create a /tours/page endpoint 337 00:15:07,550 --> 00:15:09,410 ‫and paste the number six to it 338 00:15:09,410 --> 00:15:11,850 ‫in order to request page number six. 339 00:15:11,850 --> 00:15:14,340 ‫This way, we would then state on the client 340 00:15:14,340 --> 00:15:15,410 ‫because on a client, 341 00:15:15,410 --> 00:15:18,320 ‫we would already know that we're on page five 342 00:15:18,320 --> 00:15:20,750 ‫and so all we had to do is to just add one 343 00:15:20,750 --> 00:15:22,750 ‫and then request page number six. 344 00:15:22,750 --> 00:15:23,920 ‫So the server doesn't have 345 00:15:23,920 --> 00:15:25,840 ‫to remember anything in this case. 346 00:15:25,840 --> 00:15:27,940 ‫All it has to do is to send back data 347 00:15:27,940 --> 00:15:30,840 ‫for page number six as we requested. 348 00:15:30,840 --> 00:15:33,891 ‫And by the way, statelessness and statefulness, 349 00:15:33,891 --> 00:15:35,760 ‫which is the opposite, 350 00:15:35,760 --> 00:15:38,560 ‫are very important concepts in computer science 351 00:15:38,560 --> 00:15:40,800 ‫and application design in general. 352 00:15:40,800 --> 00:15:44,070 ‫So, it's a good idea to actually have some understanding 353 00:15:44,070 --> 00:15:47,331 ‫what a stateless API is and how it works. 354 00:15:47,331 --> 00:15:50,280 ‫Anyway, this was a huge lecture, 355 00:15:50,280 --> 00:15:52,670 ‫but also one of the most important ones. 356 00:15:52,670 --> 00:15:55,700 ‫I cannot stress that enough and I actually think 357 00:15:55,700 --> 00:15:57,800 ‫that you can see that, right? 358 00:15:57,800 --> 00:16:00,803 ‫Anyway, let's now finally get back to our code.