1 00:00:03,200 --> 00:00:09,035 Let me give you a brief rest. Got you there. 2 00:00:09,035 --> 00:00:11,535 What I meant to say was let me give you 3 00:00:11,535 --> 00:00:16,420 a brief overview of Representational State Transfer. 4 00:00:16,420 --> 00:00:18,460 What exactly is REST? 5 00:00:18,460 --> 00:00:22,670 How do we make use of it in our React application, 6 00:00:22,670 --> 00:00:26,130 and how do we make use of this to communicate with the server? 7 00:00:26,130 --> 00:00:29,455 How does a server support REST API, 8 00:00:29,455 --> 00:00:34,615 and how do we access the REST API from our React application? 9 00:00:34,615 --> 00:00:39,230 Let's talk about that a little bit more in this lesson. 10 00:00:39,230 --> 00:00:47,680 I'm sure you've heard the term web services being mentioned in the IT world very often. 11 00:00:47,680 --> 00:00:49,895 What exactly are web services? 12 00:00:49,895 --> 00:00:55,520 Web Services are a way of designing systems to support interoperability 13 00:00:55,520 --> 00:01:01,745 among systems that are connected over a network like the internet as we see today. 14 00:01:01,745 --> 00:01:05,504 This is what we refer to as a service-oriented architecture. 15 00:01:05,504 --> 00:01:09,170 Now, what this means is that you provide 16 00:01:09,170 --> 00:01:14,870 a standardized way for two machines that are connected to the internet to be able to 17 00:01:14,870 --> 00:01:17,720 communicate with each other at 18 00:01:17,720 --> 00:01:24,660 the application layer level for web-based applications using open standards. 19 00:01:24,660 --> 00:01:29,175 Now, I have used a lot of jargon there. 20 00:01:29,175 --> 00:01:32,000 Let's try to break them down and understand 21 00:01:32,000 --> 00:01:36,195 a little bit about each of that in this lecture. 22 00:01:36,195 --> 00:01:43,390 Two common approaches that are used for supporting web services are SOAP. 23 00:01:43,390 --> 00:01:49,550 The Simple Object Access Protocol based web services which uses 24 00:01:49,550 --> 00:01:52,805 the web services description language for 25 00:01:52,805 --> 00:01:57,080 specifying how the two endpoints communicate with each other. 26 00:01:57,080 --> 00:02:01,700 Typically SOAP is based on using XML as 27 00:02:01,700 --> 00:02:07,340 the format for the messages being exchanged between the two endpoints. 28 00:02:07,340 --> 00:02:12,975 Representational State Transfer or REST also uses web standards, 29 00:02:12,975 --> 00:02:17,240 but the exchange of data between the two endpoints could be either XML or 30 00:02:17,240 --> 00:02:22,385 increasingly using JSON as the format. 31 00:02:22,385 --> 00:02:29,705 The REST way of interoperability is simpler compared to SOAP and hence, 32 00:02:29,705 --> 00:02:37,650 REST has found a lot wider deployment in the web services world. 33 00:02:37,650 --> 00:02:41,215 Typically, client-server communication is 34 00:02:41,215 --> 00:02:45,830 facilitated using REST where the server supports a REST API and 35 00:02:45,830 --> 00:02:49,960 the client can then invoke the REST API endpoints in order 36 00:02:49,960 --> 00:02:54,595 to obtain information or to upload information to the server. 37 00:02:54,595 --> 00:02:59,885 Again, I have mentioned the word invoke the REST API endpoints, 38 00:02:59,885 --> 00:03:03,210 so these are a few terms that I have used. 39 00:03:03,210 --> 00:03:07,385 Let's clarify some of these in the next few slides. 40 00:03:07,385 --> 00:03:12,590 Representational State Transfer is a style of software architecture 41 00:03:12,590 --> 00:03:18,200 that is specially designed for distributed hypermedia over the World Wide Web. 42 00:03:18,200 --> 00:03:24,604 Now this was first introduced by Roy Fielding in his PhD thesis. 43 00:03:24,604 --> 00:03:26,990 Now this is one of those PhD theses 44 00:03:26,990 --> 00:03:29,660 that actually produced something useful for the world. 45 00:03:29,660 --> 00:03:38,690 So this has found again a lot of traction in the web services world. 46 00:03:38,690 --> 00:03:42,800 This is a collection of network principles that outline how 47 00:03:42,800 --> 00:03:47,300 resources can be made available on servers 48 00:03:47,300 --> 00:03:50,950 and these resources can be accessed from clients 49 00:03:50,950 --> 00:03:56,285 by identifying the resources using rest API endpoints. 50 00:03:56,285 --> 00:03:58,855 Within Representational State Transfer, 51 00:03:58,855 --> 00:04:01,050 there are four basic design principles. 52 00:04:01,050 --> 00:04:05,375 First and foremost, REST is built upon HTTP protocol, 53 00:04:05,375 --> 00:04:11,365 so it uses all the HTTP methods that we have already seen in the previous lesson. 54 00:04:11,365 --> 00:04:15,045 Second, REST is designed to be stateless, 55 00:04:15,045 --> 00:04:17,930 meaning that the server doesn't store any information about 56 00:04:17,930 --> 00:04:21,450 the state after the communication is completed. 57 00:04:21,450 --> 00:04:25,615 So when a server receives the request, the server replies, 58 00:04:25,615 --> 00:04:29,110 and then after that it doesn't remember 59 00:04:29,110 --> 00:04:33,340 anything more about the conversation between the client and the server. 60 00:04:33,340 --> 00:04:38,635 Third, the REST way of providing resources is to 61 00:04:38,635 --> 00:04:44,945 expose a directory structure like URLs (Uniform Resource Locators - URLs). 62 00:04:44,945 --> 00:04:50,230 Fourth, the format for data exchange is typically JSON 63 00:04:50,230 --> 00:04:56,145 or XML or both can be supported using REST. 64 00:04:56,145 --> 00:05:03,350 One of the motivations for Roy suggesting REST as a way for supporting web services is 65 00:05:03,350 --> 00:05:06,620 that it captures all the things that are good about 66 00:05:06,620 --> 00:05:10,880 the World Wide Web and that made the World Wide Web successful. 67 00:05:10,880 --> 00:05:14,040 The use of Uniform Resource Indicators or 68 00:05:14,040 --> 00:05:18,320 Uniform Resource Locators (URLs) which allow you to 69 00:05:18,320 --> 00:05:23,170 address resources by specifying them as a URL. 70 00:05:23,170 --> 00:05:29,390 The second one, being a protocol that lives on top of HTTP protocol. 71 00:05:29,390 --> 00:05:34,600 HTTP has already found wide deployment in the internet. 72 00:05:34,600 --> 00:05:40,135 Third, the request response cycle that HTTP is well-known for. 73 00:05:40,135 --> 00:05:42,420 So you send a request, 74 00:05:42,420 --> 00:05:45,775 the server receives your request, processes the request, 75 00:05:45,775 --> 00:05:49,530 send the response to the request, 76 00:05:49,530 --> 00:05:51,830 and the client receives the response, 77 00:05:51,830 --> 00:05:54,765 acts upon that, and may generate further requests. 78 00:05:54,765 --> 00:05:58,580 So, this approach of the request response cycle is very 79 00:05:58,580 --> 00:06:03,115 well established with HTTP and the World Wide Web. 80 00:06:03,115 --> 00:06:08,505 Now, the HTTP protocol as we have seen earlier, 81 00:06:08,505 --> 00:06:13,650 we will use all the various verbs that HTTP provides. 82 00:06:13,650 --> 00:06:15,520 specifically, the GET, PUT, 83 00:06:15,520 --> 00:06:18,635 POST and DELETE for being able to 84 00:06:18,635 --> 00:06:23,480 specify operations to be done on resources that are stored on the server-side. 85 00:06:23,480 --> 00:06:27,470 So for example, if you do an HTTP GET request, 86 00:06:27,470 --> 00:06:30,125 you are asking for the server to return the resource. 87 00:06:30,125 --> 00:06:32,415 If you do a POST request, 88 00:06:32,415 --> 00:06:35,415 you're asking for the server to create a new resource. 89 00:06:35,415 --> 00:06:36,670 If you do a PUT request, 90 00:06:36,670 --> 00:06:39,650 you are asking for the server to update an existing resource. 91 00:06:39,650 --> 00:06:42,170 And if you issue a DELETE request, 92 00:06:42,170 --> 00:06:45,020 you are asking for the server to delete the resource 93 00:06:45,020 --> 00:06:48,070 that is identified by the particular URL. 94 00:06:48,070 --> 00:06:51,735 Also, it tries to preserve Idempotence. 95 00:06:51,735 --> 00:06:56,165 Some operations, when they are performed even repeatedly, 96 00:06:56,165 --> 00:06:58,225 will not cause any change of state. 97 00:06:58,225 --> 00:07:02,085 Some other operations, if you do them successively, 98 00:07:02,085 --> 00:07:05,170 they may cause a change of state. 99 00:07:05,170 --> 00:07:08,780 So you need to be careful about which operations can be repeated without 100 00:07:08,780 --> 00:07:14,395 any damaging consequences and which have to be very carefully done. 101 00:07:14,395 --> 00:07:21,864 In the REST world you often hear people talking about nouns, verbs, and representations. 102 00:07:21,864 --> 00:07:27,875 Now, we'll clarify each one of these in a little more detail in the next few slides. 103 00:07:27,875 --> 00:07:31,760 Nouns specifically refer to resources and these resources are 104 00:07:31,760 --> 00:07:36,320 usually identified by their URLs and these are unconstrained. 105 00:07:36,320 --> 00:07:40,700 Verbs are constraint and these specify the actions to be 106 00:07:40,700 --> 00:07:45,010 done on the resources and representations as we see. 107 00:07:45,010 --> 00:07:47,285 When the information needs to be conveyed from 108 00:07:47,285 --> 00:07:49,910 the server to the client or from the client to the server, 109 00:07:49,910 --> 00:07:51,855 how you encode the information. 110 00:07:51,855 --> 00:07:56,520 Typically, either using JSON or using XML. 111 00:07:56,520 --> 00:08:01,895 Resource is the key abstraction that REST works around. 112 00:08:01,895 --> 00:08:06,810 So, the information is abstracted in the form of a resource and the resource 113 00:08:06,810 --> 00:08:12,475 is identified by specifying it by using a URL. 114 00:08:12,475 --> 00:08:18,395 So, any information that can be encapsulated and be made available, 115 00:08:18,395 --> 00:08:20,720 can be identified as a resource. 116 00:08:20,720 --> 00:08:26,980 A piece of information like the current weather in Hong Kong could be a resource, 117 00:08:26,980 --> 00:08:29,345 an image could be a resource, 118 00:08:29,345 --> 00:08:33,985 a stock price information could be a resource and so on. 119 00:08:33,985 --> 00:08:38,920 So, whatever you define as a piece of information that a client may be interested in, 120 00:08:38,920 --> 00:08:41,430 can be identified as a resource. 121 00:08:41,430 --> 00:08:44,045 You can even deal with resources as collection of 122 00:08:44,045 --> 00:08:48,740 resources that the server may send up to the client. 123 00:08:48,740 --> 00:08:54,145 An example of how you name resources is illustrated here. 124 00:08:54,145 --> 00:08:57,740 So we use URIs to identify the source. 125 00:08:57,740 --> 00:09:03,355 A quick reading of these specification or the URIs here will 126 00:09:03,355 --> 00:09:10,460 easily enable you to understand what we are referring to by using these URIs. 127 00:09:10,460 --> 00:09:14,420 So, for example, something which ends with dishes/, 128 00:09:14,420 --> 00:09:19,315 you automatically assume that this is referring to a collection of dishes. 129 00:09:19,315 --> 00:09:22,795 But dishes/123 for example, 130 00:09:22,795 --> 00:09:28,250 might mean dish number 123 in this case and so on. 131 00:09:28,250 --> 00:09:31,320 So, it is very easy to save and you can specify 132 00:09:31,320 --> 00:09:34,650 a collection of resources and be able to identify 133 00:09:34,650 --> 00:09:38,815 them as a collection and then download them as a collection or you can 134 00:09:38,815 --> 00:09:43,965 identify an individual resource and say that you want that particular resource. 135 00:09:43,965 --> 00:09:50,395 Now, these resources can be organized into a hierarchy of the specification of this URI. 136 00:09:50,395 --> 00:09:52,740 So, as you traverse the path, 137 00:09:52,740 --> 00:09:58,325 you go from the more general to the more specific of the resource. 138 00:09:58,325 --> 00:10:02,110 This directory structure enables you to identify the resources 139 00:10:02,110 --> 00:10:07,780 that you use or provide from your server-side very easily. 140 00:10:07,780 --> 00:10:11,585 The second part of the REST API are the verbs. 141 00:10:11,585 --> 00:10:16,760 In particular, we are interested in the four verbs of HTTP the GET, 142 00:10:16,760 --> 00:10:19,140 PUT, POST and DELETE. 143 00:10:19,140 --> 00:10:24,410 In this case, these verbs will be mapped into actions that we 144 00:10:24,410 --> 00:10:29,755 want to be performed on the resource, on the server-side. 145 00:10:29,755 --> 00:10:34,170 A GET would mean you want to perform a read operation on the resource. 146 00:10:34,170 --> 00:10:39,980 So, which means that a client sending a GET request is indicating to the server that it 147 00:10:39,980 --> 00:10:43,480 wants to obtain a representation 148 00:10:43,480 --> 00:10:46,380 of that resource from the server-side to the client-side. 149 00:10:46,380 --> 00:10:48,960 A POST means that you want to create 150 00:10:48,960 --> 00:10:52,755 a new resource and then you will specify the details of the resource 151 00:10:52,755 --> 00:10:55,795 in the representation that is used for 152 00:10:55,795 --> 00:10:59,799 specifying the resource and then send that information over to the server-side, 153 00:10:59,799 --> 00:11:03,285 so that the server will create that resource on your behalf. 154 00:11:03,285 --> 00:11:06,370 A PUT would be modification of resources and 155 00:11:06,370 --> 00:11:09,955 a DELETE as you would expect is deletion of the resources. 156 00:11:09,955 --> 00:11:12,995 So, as you can see, the four verbs; 157 00:11:12,995 --> 00:11:15,110 GET, POST, PUT and DELETE, 158 00:11:15,110 --> 00:11:19,180 are mapped into the four CRUD operations that you can carry 159 00:11:19,180 --> 00:11:24,035 out on a database that stores these resources on the server-side, 160 00:11:24,035 --> 00:11:27,815 the READ, CREATE, UPDATE, and DELETE operations. 161 00:11:27,815 --> 00:11:33,760 Elaborating further, the HTTP GET is a way of specifying that you 162 00:11:33,760 --> 00:11:36,950 want the information or the representation of 163 00:11:36,950 --> 00:11:40,235 the resource to be returned to the client from the server-side. 164 00:11:40,235 --> 00:11:43,890 So, when you issue a GET request to a REST API endpoint, 165 00:11:43,890 --> 00:11:49,130 you are asking for either a collection of resources represented by 166 00:11:49,130 --> 00:11:57,530 URI or a specific resource which is identified by the ID of that particular resource, 167 00:11:57,530 --> 00:11:59,490 specified within the URL. 168 00:11:59,490 --> 00:12:01,000 So, as you see in this example, 169 00:12:01,000 --> 00:12:03,800 if you say, dishes/452, 170 00:12:03,800 --> 00:12:08,320 you are meaning to say that dish number 452 with 171 00:12:08,320 --> 00:12:13,075 the ID 452 should be returned to the client-side. 172 00:12:13,075 --> 00:12:18,175 Similarly, the POST operation as we saw is used to create the resource. 173 00:12:18,175 --> 00:12:20,065 So, when you create the resource, 174 00:12:20,065 --> 00:12:26,920 the content of describing the resource would be in the form of a JSON representation or 175 00:12:26,920 --> 00:12:29,790 an XML representation and that will be included in 176 00:12:29,790 --> 00:12:34,075 the body of the request message that is sent to the server-side. 177 00:12:34,075 --> 00:12:38,095 So, a POST operation expects a representation of 178 00:12:38,095 --> 00:12:42,870 the resource in either JSON or XML format in the body of the request message. 179 00:12:42,870 --> 00:12:44,890 When the server receives that request message, 180 00:12:44,890 --> 00:12:49,960 the server creates that resource on the server-side and then returns 181 00:12:49,960 --> 00:12:58,030 either a conformation or a error to indicate that the resource creation failed. 182 00:12:58,030 --> 00:13:02,725 Similarly, a PUT operation is used to update a resource. 183 00:13:02,725 --> 00:13:06,315 When you do a PUT operation on a resource on the server-side, 184 00:13:06,315 --> 00:13:10,200 you may send back the modification 185 00:13:10,200 --> 00:13:15,470 either by specifying only the partial modification that you want to effect on 186 00:13:15,470 --> 00:13:20,200 the particular resource in the body of the reply message or you may send 187 00:13:20,200 --> 00:13:25,345 the complete representation of the resource in the body of the message. 188 00:13:25,345 --> 00:13:28,705 Depending on the arrangement between the client and the server, 189 00:13:28,705 --> 00:13:37,195 the server expects the information to be passed on in the body of the request message. 190 00:13:37,195 --> 00:13:42,600 A DELETE operation as you would expect deletes the existing resource. 191 00:13:42,600 --> 00:13:45,460 Now, in this particular case, 192 00:13:45,460 --> 00:13:49,670 of course a DELETE operation would be idempotent because if you 193 00:13:49,670 --> 00:13:54,145 try to delete a resource and the resource exists, it will be deleted. 194 00:13:54,145 --> 00:13:56,445 If you are trying to delete a non-existing resource, 195 00:13:56,445 --> 00:14:01,220 it won't cause any further modification to the server-side, 196 00:14:01,220 --> 00:14:06,165 except that the server will reply with an error saying that the resource doesn't exist. 197 00:14:06,165 --> 00:14:12,530 But, nevertheless, DELETE is an example of an idempotent operation in this case. 198 00:14:12,530 --> 00:14:16,510 Similarly, the GET operation is also an idempotent operation because it is 199 00:14:16,510 --> 00:14:20,885 not making any modifications to the resource on the server-side. 200 00:14:20,885 --> 00:14:26,925 POST and PUT of course are going to modify the resource on the server-side, 201 00:14:26,925 --> 00:14:31,940 either create a new resource or modify an existing resource on the server-side. 202 00:14:31,940 --> 00:14:34,060 Of course, the representations, 203 00:14:34,060 --> 00:14:36,730 as I have been emphasizing, 204 00:14:36,730 --> 00:14:43,980 the two common formats for representing is either JSON or XML. 205 00:14:43,980 --> 00:14:47,105 The last part that we need to emphasize is 206 00:14:47,105 --> 00:14:51,060 that server-side should be completely stateless, 207 00:14:51,060 --> 00:14:53,640 which means that the server-side does not track 208 00:14:53,640 --> 00:14:59,145 the client state because if the server needs to track the clients state, 209 00:14:59,145 --> 00:15:00,935 it will not be scalable. 210 00:15:00,935 --> 00:15:05,160 So, for a scalable implementation of the server-side, 211 00:15:05,160 --> 00:15:09,620 you normally use a stateless server on the server-side. 212 00:15:09,620 --> 00:15:12,910 So, every request that the client sends to the server will be 213 00:15:12,910 --> 00:15:16,490 treated as an independent request and will 214 00:15:16,490 --> 00:15:20,330 not reflect upon previous requests 215 00:15:20,330 --> 00:15:24,685 that have already been handled by the server from that particular client. 216 00:15:24,685 --> 00:15:29,605 So, it's the responsibility of the client to track its own state, 217 00:15:29,605 --> 00:15:34,635 either in the form of using cookies or using a client-side database, 218 00:15:34,635 --> 00:15:37,435 whatever means that is suitable. 219 00:15:37,435 --> 00:15:41,790 Now, this approach where the client tracks its own state is 220 00:15:41,790 --> 00:15:44,815 a lot more scalable because each individual client 221 00:15:44,815 --> 00:15:48,240 will be responsible for tracking its own state. 222 00:15:48,240 --> 00:15:53,840 This is where the client-side MVC setup helps us in this regard. 223 00:15:53,840 --> 00:15:57,440 Finally, we are not yet done with REST. 224 00:15:57,440 --> 00:16:04,145 We will see more of REST in the exercises that follow in this particular lesson 225 00:16:04,145 --> 00:16:12,310 and then also we will see more details about REST usage in the rest of this course.