1 00:00:00,000 --> 00:00:03,979 [MUSIC] 2 00:00:03,979 --> 00:00:06,750 Let me give you a brief rest. 3 00:00:08,010 --> 00:00:09,480 Got you there! 4 00:00:09,480 --> 00:00:10,800 What I meant to say was, 5 00:00:10,800 --> 00:00:16,860 let me give you a brief overview of representational state transfer. 6 00:00:16,860 --> 00:00:18,670 What exactly is rest? 7 00:00:18,670 --> 00:00:22,900 How do we make use of it in our angular application and 8 00:00:22,900 --> 00:00:26,450 how do we make use of this to communicate with the server? 9 00:00:26,450 --> 00:00:30,050 How does a server support REST API and 10 00:00:30,050 --> 00:00:35,060 how do we access the REST API from our Angular application? 11 00:00:35,060 --> 00:00:39,170 Let's talk about that a little bit more in this lesson. 12 00:00:39,170 --> 00:00:43,880 In this particular lecture, I will give you a brief overview of REST. 13 00:00:46,010 --> 00:00:50,620 I'm sure you've heard the term Web Services being mentioned 14 00:00:50,620 --> 00:00:53,990 in the IT world very often. 15 00:00:53,990 --> 00:00:56,160 What exactly are web services? 16 00:00:56,160 --> 00:01:01,980 Web services are a way of designing systems to support interoperability among 17 00:01:01,980 --> 00:01:07,920 systems that are connected over a network, like the Internet as we see today. 18 00:01:07,920 --> 00:01:11,830 This is what we refer to as a service oriented architecture. 19 00:01:11,830 --> 00:01:18,100 Now, what this means is that you provide a standardized way for two machines 20 00:01:18,100 --> 00:01:22,190 that are connected to the internet to be able to communicate with each other. 21 00:01:23,670 --> 00:01:26,970 Their application layout level for 22 00:01:26,970 --> 00:01:30,920 database applications using open standards. 23 00:01:30,920 --> 00:01:34,660 Now, I have used a lot of jargon there. 24 00:01:35,710 --> 00:01:37,420 Let's try to break them down and 25 00:01:37,420 --> 00:01:41,640 understand a little bit about each of that in this lecture. 26 00:01:42,640 --> 00:01:49,570 Two common approaches that are used for supporting web services are SOAP, 27 00:01:49,570 --> 00:01:54,720 the simple object access protocol based web services, 28 00:01:54,720 --> 00:01:58,820 which uses the web services description language for 29 00:01:58,820 --> 00:02:03,150 specifying how the two end points communicate with each other. 30 00:02:03,150 --> 00:02:07,667 And typically, soap is based on using XML as 31 00:02:07,667 --> 00:02:12,240 the format for the messages being exchanged between the two endpoints. 32 00:02:13,990 --> 00:02:19,910 The presentational state transfer or rest also uses web standards, but the exchange 33 00:02:19,910 --> 00:02:24,020 of data between the two endpoints could be either XML or increasingly. 34 00:02:25,150 --> 00:02:28,960 Using JSON as the format. 35 00:02:28,960 --> 00:02:34,960 The REST way of interoperability is simpler compared to SOAP and 36 00:02:34,960 --> 00:02:42,940 hence REST has found a lot wider deployment in the web services left. 37 00:02:43,950 --> 00:02:49,230 Typically, client server communication is facilitated using REST 38 00:02:49,230 --> 00:02:54,830 where the server supports the REST API and the client can then invoke their REST API 39 00:02:54,830 --> 00:03:01,000 endpoints in order to obtain information or to upload information to the server. 40 00:03:01,000 --> 00:03:05,910 Again, I have mentioned the word, invoke that REST API end point. 41 00:03:05,910 --> 00:03:09,290 So these are a few terms that I have used. 42 00:03:09,290 --> 00:03:12,460 Let's clarify some of these in the next few slides. 43 00:03:13,790 --> 00:03:18,710 Representational state transfer is a style of software architecture that 44 00:03:18,710 --> 00:03:23,360 is specially designed for distributed hypermedia over the World Wide Web. 45 00:03:24,770 --> 00:03:30,810 Now this was first introduced by Roy Fielding in his PhD thesis. 46 00:03:30,810 --> 00:03:33,750 Now, this is one of those PhD thesis that actually produced 47 00:03:33,750 --> 00:03:35,970 something useful for the world. 48 00:03:35,970 --> 00:03:44,250 So this has found again a lot of traction in the web services world. 49 00:03:44,250 --> 00:03:50,410 This is a collection of network principles that outline how resources can be 50 00:03:51,630 --> 00:03:57,060 made available on servers, and these resources can be accessed from clients 51 00:03:57,060 --> 00:04:02,520 by identifying the resources using REST API endpoints. 52 00:04:02,520 --> 00:04:07,150 Within Representational State Transfer there are four basic design principles. 53 00:04:07,150 --> 00:04:11,310 First and foremost, REST is built upon HTTP protocol. 54 00:04:11,310 --> 00:04:17,800 So it uses all the HTTP methods That we have already seen in the previous lesson. 55 00:04:17,800 --> 00:04:22,750 Second, REST is designed to be stateless, meaning that the server doesn't store 56 00:04:22,750 --> 00:04:27,350 any information about the state after the communication is completed. 57 00:04:27,350 --> 00:04:31,850 So when a server receives the request, the server replies and 58 00:04:31,850 --> 00:04:37,020 then after that, it doesn't remember anything more about that 59 00:04:37,020 --> 00:04:39,730 conversation between the client and the server. 60 00:04:39,730 --> 00:04:44,620 Third the REST way of providing resources is to 61 00:04:44,620 --> 00:04:49,990 expose a directory structure like URLs uniform resource locators URLs. 62 00:04:51,090 --> 00:04:57,210 And fourth their format for data exchange is typically JSON or 63 00:04:57,210 --> 00:05:02,360 XML, or both that can be supported using REST. 64 00:05:02,360 --> 00:05:07,940 One of the motivations for rise suggesting REST as a way for supporting web 65 00:05:07,940 --> 00:05:14,060 services is that it captures all the thing that are good of all the World Wide Web. 66 00:05:14,060 --> 00:05:17,130 And that made the Word Wide Web successful. 67 00:05:17,130 --> 00:05:23,240 The use of Uniform Resource Indicators or Uniform Resource Locators, URLs, 68 00:05:23,240 --> 00:05:28,660 which allow you to address resources by specifying them as a URL, 69 00:05:28,660 --> 00:05:35,370 the second one being a protocol that rides on top of HTTP protocol. 70 00:05:35,370 --> 00:05:40,820 HTTP has already found wide deployment in the Internet. 71 00:05:40,820 --> 00:05:46,370 Third, the request response cycle that HTTP is well known for. 72 00:05:46,370 --> 00:05:51,850 So you send a request, the server receives your request, processes the request, 73 00:05:51,850 --> 00:05:57,835 sends the response to the request, and that client receives the response, 74 00:05:57,835 --> 00:06:00,845 acts upon that, and may generate further requests. 75 00:06:00,845 --> 00:06:06,815 So, this approach of the request response cycle is very well established with HTTP 76 00:06:06,815 --> 00:06:14,740 and the worldwide Web THe HTTP protocol as we have seen earlier, 77 00:06:14,740 --> 00:06:19,670 we will use all the various verbs that HTTP provides. 78 00:06:19,670 --> 00:06:23,120 Specifically, the gate put post delete. 79 00:06:23,120 --> 00:06:26,730 For being able to specify operations to be done 80 00:06:26,730 --> 00:06:29,680 on resources that are stored on the server side. 81 00:06:29,680 --> 00:06:34,320 So for example, if you do an HTTP GET request, you are asking for 82 00:06:34,320 --> 00:06:36,180 the server to return the source. 83 00:06:36,180 --> 00:06:41,410 If you do a POST request, you are asking for the server to create a new resource. 84 00:06:41,410 --> 00:06:44,330 If you do a PUT request, you are asking for the server to update 85 00:06:44,330 --> 00:06:48,780 an existing resource and if you issue a delete request you're asking for 86 00:06:48,780 --> 00:06:54,210 the server to delete the resource that is identified by that particular URL. 87 00:06:54,210 --> 00:06:57,890 Also, it tries to preserve idempotence. 88 00:06:57,890 --> 00:07:00,970 Some operations when they are performed 89 00:07:00,970 --> 00:07:04,370 Even repeatedly will not cause any change of state. 90 00:07:04,370 --> 00:07:08,160 Some other operations, if you do them successively, 91 00:07:08,160 --> 00:07:11,170 they may cause a change of state. 92 00:07:11,170 --> 00:07:14,780 So you need to be careful about which operations can be repeated without 93 00:07:14,780 --> 00:07:16,660 any damaging consequences. 94 00:07:16,660 --> 00:07:19,570 And which have to be very carefully done. 95 00:07:21,070 --> 00:07:25,530 In the REST world, you often hear people talking about nouns, 96 00:07:25,530 --> 00:07:28,230 verbs and representations. 97 00:07:28,230 --> 00:07:34,120 Now we'll clarify each one of these in a little more detail in the next few slides. 98 00:07:34,120 --> 00:07:36,720 Nouns, specifically, they're full of resources and 99 00:07:36,720 --> 00:07:42,580 these resources are usually identified by their URL's and these are unconstrained. 100 00:07:42,580 --> 00:07:48,890 Verbs are constrained and these specified actions to be done on the resources. 101 00:07:48,890 --> 00:07:53,200 And the presentations as we see when the information needs to be conveyed from 102 00:07:53,200 --> 00:07:54,560 the server to the client or 103 00:07:54,560 --> 00:07:58,150 from the client to the server, how you encode the information. 104 00:07:58,150 --> 00:08:02,840 Typically either using JSON or using XML. 105 00:08:02,840 --> 00:08:08,150 Resource is the key abstraction that REST works around so 106 00:08:08,150 --> 00:08:11,787 that information is abstracted in the resource. 107 00:08:11,787 --> 00:08:18,690 And the resource is identified by specifying it by using a URI. 108 00:08:18,690 --> 00:08:23,040 So any information that can be encapsulated and 109 00:08:23,040 --> 00:08:26,980 be made available can be identified as a resource. 110 00:08:26,980 --> 00:08:33,145 A piece of information like that current weather in Hong Kong could be a resource, 111 00:08:33,145 --> 00:08:35,465 an image could be a resource. 112 00:08:35,465 --> 00:08:39,915 A stock price information could be a resource, and so on. 113 00:08:39,915 --> 00:08:43,905 So whatever you define as a piece of information that a client may be 114 00:08:43,905 --> 00:08:47,515 interested in, can be identified as a resource. 115 00:08:47,515 --> 00:08:50,965 You can even deal with resources as collection of resources 116 00:08:50,965 --> 00:08:55,070 that that server may send up to that client. 117 00:08:55,070 --> 00:09:00,380 An example of how you name resources is illustrated here. 118 00:09:00,380 --> 00:09:03,898 So we use URIs to identify the source. 119 00:09:03,898 --> 00:09:09,575 A quick reading of the specification or the URLs here will 120 00:09:09,575 --> 00:09:16,525 easily enable you to understand what we are referring to by using these URLs. 121 00:09:16,525 --> 00:09:19,675 So for example, something which ends with dishes/, 122 00:09:19,675 --> 00:09:25,495 you automatically assume that this is referring to a collection of dishes. 123 00:09:25,495 --> 00:09:28,909 Like dishes/123 for example, 124 00:09:28,909 --> 00:09:34,150 might mean dish number 123, in this case and so on. 125 00:09:34,150 --> 00:09:39,530 So it's very easy to say that you can specify a collection of resources, and 126 00:09:39,530 --> 00:09:43,800 be able to identify them as a collection, and then download them as a collection. 127 00:09:43,800 --> 00:09:46,960 Or, you can identify an individual resource, and 128 00:09:46,960 --> 00:09:50,070 say that you want that particular resource. 129 00:09:50,070 --> 00:09:53,378 Now these resources can be organized into a hierarchy 130 00:09:53,378 --> 00:09:56,500 that specification of this URI. 131 00:09:56,500 --> 00:09:58,860 So as you traverse the path, 132 00:09:58,860 --> 00:10:04,460 you go from the more general to the more specific of that resource. 133 00:10:04,460 --> 00:10:08,260 This directory structure enables you to identify the resources that 134 00:10:09,320 --> 00:10:14,170 you provide from your service site very easily. 135 00:10:14,170 --> 00:10:17,970 The second part of the REST API are the words. 136 00:10:17,970 --> 00:10:22,150 In particular we are interested in the 4 verbs of HTTP to get, 137 00:10:22,150 --> 00:10:25,320 put, post, and delete. 138 00:10:25,320 --> 00:10:30,310 In this case these verbs will be nap in to actions that we 139 00:10:30,310 --> 00:10:36,165 want to be performed on the resource on the server side. 140 00:10:36,165 --> 00:10:40,760 GETt would mean you want to perform a read operation on the resource, which means 141 00:10:40,760 --> 00:10:46,550 that a client sending a get request is indicating to the server that it wants to 142 00:10:46,550 --> 00:10:52,710 obtain that presentation of data source from the server site to the client site. 143 00:10:52,710 --> 00:10:56,770 POST means means you want to create a new resource and then you will. 144 00:10:56,770 --> 00:11:01,700 Specify the details of the resource in the representation, but is used for 145 00:11:01,700 --> 00:11:02,850 specifying the resource. 146 00:11:02,850 --> 00:11:05,900 Then send the information over to the server side, so 147 00:11:05,900 --> 00:11:09,590 that the server will create the resource on your behalf. 148 00:11:09,590 --> 00:11:12,310 A PUT would be modification of resources, and 149 00:11:12,310 --> 00:11:16,030 delete, as you would expect, is deletion of the sources. 150 00:11:16,030 --> 00:11:20,550 So, as you can see the four Verbs get, post, put and 151 00:11:20,550 --> 00:11:25,670 delete are mapped into the four CRUD operations that you can carry out 152 00:11:25,670 --> 00:11:30,140 on a database that stores these resources on the server side. 153 00:11:30,140 --> 00:11:34,130 The read, create, update and delete operations. 154 00:11:34,130 --> 00:11:39,140 Elaborating further, the HTTP GET is a way of specifying. 155 00:11:39,140 --> 00:11:43,560 That you want the information or their presentation of the resource to be 156 00:11:43,560 --> 00:11:46,280 returned to the client from the server site. 157 00:11:46,280 --> 00:11:49,980 So when you issue a GET request to a REST API endpoint. 158 00:11:49,980 --> 00:11:54,370 You are asking for either a collection of resources that are presented by 159 00:11:55,890 --> 00:12:01,790 Uri or a specific resource which is identified by the ID of 160 00:12:01,790 --> 00:12:06,950 that particular resources specified within the URL so as you see in this example, 161 00:12:06,950 --> 00:12:13,090 if you dishes/452, you are meaning to say that dish number 452, 162 00:12:13,090 --> 00:12:16,950 with the id 452 should be returned to the client side. 163 00:12:19,370 --> 00:12:24,210 Similarly, the post operation, as we saw, is used to create the resource. 164 00:12:24,210 --> 00:12:29,940 So when you create the resource, the content of describing the resource would 165 00:12:29,940 --> 00:12:34,830 be in the form of a JSON representation or a XML representation, and that would be 166 00:12:34,830 --> 00:12:40,220 included in the body of the request message that is sent to the server side. 167 00:12:40,220 --> 00:12:43,900 So a post operation expects a representation 168 00:12:43,900 --> 00:12:49,040 of the resource in either JSON or XML format in the body of the request message. 169 00:12:49,040 --> 00:12:53,250 And the server receives such request message, the server creates that 170 00:12:53,250 --> 00:12:58,440 resource on the server side and then returns either a confirmation or 171 00:12:58,440 --> 00:13:04,390 a error to indicate that the resource creation failed. 172 00:13:04,390 --> 00:13:08,820 Similarly it put operation easy use to update a resource. 173 00:13:08,820 --> 00:13:14,630 When you do a PUT operation on a resource on the server side, you may send back 174 00:13:14,630 --> 00:13:19,630 the modification either by specifying only the partial modification 175 00:13:19,630 --> 00:13:25,450 that you want to effect on the particular resource in body of the reply message. 176 00:13:25,450 --> 00:13:29,370 Or you may send the complete representation of the resource 177 00:13:29,370 --> 00:13:33,890 in the body of the message, depending on the arrangement between the client and 178 00:13:33,890 --> 00:13:38,760 the server, the server expects the information to be 179 00:13:38,760 --> 00:13:43,320 passed on in the body of the request message. 180 00:13:43,320 --> 00:13:48,980 DELETE operation as you would expect deletes the existing resource. 181 00:13:48,980 --> 00:13:55,150 Now in this particular case, of course, a delete operation would be because 182 00:13:55,150 --> 00:14:00,220 if you try to delete a resource and the resource exists, it will be deleted. 183 00:14:00,220 --> 00:14:02,440 If you are trying to delete a non existing resource, 184 00:14:02,440 --> 00:14:07,990 it won't cause any further modification to the server side Except 185 00:14:07,990 --> 00:14:11,808 that the server will reply with an error saying that the resource doesn't exist. 186 00:14:11,808 --> 00:14:18,700 But nevertheless, is an example of an operation in this case. 187 00:14:18,700 --> 00:14:22,810 Similarly, the get operation will also operation because it is not 188 00:14:22,810 --> 00:14:27,140 making any modification to the resource on the server site. 189 00:14:27,140 --> 00:14:32,740 Post input of course are going to modify the resource on the server side. 190 00:14:32,740 --> 00:14:34,770 You need to create a new resource or 191 00:14:34,770 --> 00:14:40,050 modify existing resource on the server side, and of course data presentations. 192 00:14:40,050 --> 00:14:45,050 As I have been emphasizing, the two common fallbacks for 193 00:14:45,050 --> 00:14:51,570 representing is either JSON XML, the last part 194 00:14:51,570 --> 00:14:57,140 that we need to emphasize is that server side should be completely stateless. 195 00:14:57,140 --> 00:15:01,190 Which means, that the server side does not track the client's state. 196 00:15:01,190 --> 00:15:07,060 Because, if the server needs to track the client's state, it will not be scalable. 197 00:15:07,060 --> 00:15:11,140 So for a scalable implementation of the server side, 198 00:15:11,140 --> 00:15:15,650 you normally use a stateless server on the server side. 199 00:15:15,650 --> 00:15:19,580 So if the request of the clients sent to the server will be treated as 200 00:15:19,580 --> 00:15:25,460 an independent request, and will not reflect upon previous 201 00:15:25,460 --> 00:15:30,790 requests that have already been handled by the server from the particular client. 202 00:15:30,790 --> 00:15:35,760 So it's the responsibility of the client to track it's own state. 203 00:15:35,760 --> 00:15:40,770 Either in the form of using cookies or using a client site database. 204 00:15:40,770 --> 00:15:43,780 Whatever means that is suitable. 205 00:15:43,780 --> 00:15:48,760 Now, this approach where the client tracks its own state is a lot more scalable, 206 00:15:48,760 --> 00:15:52,880 because your client will be responsible for tracking its own. 207 00:15:54,340 --> 00:15:58,880 And this is where the client side MVC setup helps us in this regard. 208 00:16:00,100 --> 00:16:04,920 And finally we are not yet done with REST, we will see more of 209 00:16:04,920 --> 00:16:10,280 REST in the exercises that follow in this particular lesson. 210 00:16:10,280 --> 00:16:11,563 And then also, 211 00:16:11,563 --> 00:16:17,206 we will see more details about REST usage in the rest of this course. 212 00:16:17,206 --> 00:16:20,509 [MUSIC]