WEBVTT 00:00.120 --> 00:01.030 Hello developers. 00:01.050 --> 00:02.910 And welcome back. 00:02.910 --> 00:08.200 You can often hear people talking about REST API eyes or RESTful API eyes. 00:08.310 --> 00:14.940 What does it mean in the generous framework talks we can find these puzzling quote You Keep Using That 00:14.940 --> 00:16.560 Word rest. 00:16.560 --> 00:19.010 I do not think it means what you think it means. 00:19.050 --> 00:22.690 And then right below a couple of lines from the core depths. 00:22.800 --> 00:30.960 First off the disclaimer the name jangle rest framework was decided back in early 2011 and was chosen 00:31.170 --> 00:37.010 simply to sure the project would be easily found by developers throughout the documentation. 00:37.050 --> 00:44.370 We try to use the more simple and technically correct terminology of web API use the word rest is the 00:44.370 --> 00:48.020 acronym of representational state transfer. 00:48.090 --> 00:54.600 It was conceived in use for the first time by an American computer scientist called a Roy Fielding and 00:54.600 --> 00:56.380 his doctor out teases. 00:56.430 --> 01:02.850 Fielding is an authority in computer network architecture and he also co-founded the Apache HDP web 01:02.850 --> 01:06.220 server which I'm sure you probably heard about right. 01:06.240 --> 01:10.110 And by the way you can find a link to fill this dissertation paper. 01:10.110 --> 01:13.080 Among the other reference links for this lecture. 01:13.080 --> 01:18.420 Remember you can download all the presents all the slides to the museum from the first lecture of each 01:18.420 --> 01:18.960 section. 01:19.170 --> 01:27.350 So with Resta fielding describes the specific architectural pattern for creating web APIs that use HDB 01:27.720 --> 01:32.950 as their underlying communication protocol and that must conform to the following criteria. 01:32.970 --> 01:40.860 First of all resources must be accessible via EU URL and points the EPA must use the Jason or X email 01:40.980 --> 01:42.380 as file format. 01:42.480 --> 01:49.080 They have to be stateless which means that basically a request cannot depend on any other requests and 01:49.080 --> 01:56.990 must use age GDP verbs to perform actions verbs such as Get post put delete and so on. 01:57.090 --> 02:03.480 So if rest is an architectural partner for creating web API is that use age GDP as their underlying 02:03.480 --> 02:09.240 communication protocol and must use ETP verbs to perform actions. 02:09.270 --> 02:16.940 Well it's pretty important to figure out what age should be release right and a GDP stands for. 02:16.950 --> 02:25.020 I per text transfer protocol age GDP is one of the most important and popular protocols used to transfer 02:25.020 --> 02:30.000 information on the web based on a system of requests and response messages. 02:30.000 --> 02:37.140 In a typical client server architecture so the message exchange takes place typically between a browser 02:37.190 --> 02:45.170 accessing a web server or a client app accessing a web API dough client and server can be anything really. 02:45.180 --> 02:48.790 Just think about smart fridges or smart toasters. 02:48.810 --> 02:49.810 You know what I mean. 02:49.860 --> 02:57.840 So this is a diagram of request response cycle in HDB client and server communicate by sending plain 02:57.840 --> 03:01.860 text messages where client sends a request. 03:01.860 --> 03:08.130 The server processes a response and that sends its back to the client. 03:08.220 --> 03:11.700 What does that request message look like. 03:11.700 --> 03:14.740 The request message consists of the following. 03:14.760 --> 03:19.950 First of all a request line that describes the request to implement. 03:19.980 --> 03:21.230 Now we have the request. 03:21.270 --> 03:26.010 Other fields which might contain additional information about the request. 03:26.400 --> 03:33.120 Then we have an empty line which signals that the meta information meaning the information about the 03:33.120 --> 03:38.850 request itself have been sent and then we have an optional message body. 03:38.850 --> 03:44.440 This is an example of a request line using the age TTP get method. 03:44.490 --> 03:47.280 Some people call them request a start line. 03:47.310 --> 03:50.460 OK both are ok to use. 03:50.460 --> 03:51.600 We got the method. 03:51.610 --> 03:52.960 This case is get. 03:53.040 --> 03:53.490 There we go. 03:53.490 --> 03:54.430 There you are right. 03:54.510 --> 03:58.870 Which just basically use it in defiance of the resource that you rail. 03:58.910 --> 04:04.890 This case is the home page of Google and now we got the protocol a repeat and the version one point 04:04.890 --> 04:05.640 one. 04:05.640 --> 04:12.240 So far we've seen our web API is exposed the web apps functionalities and components via U.S. rail and 04:12.240 --> 04:20.190 points so that they can be accessed by external client taps or by other parts of the same web app. 04:20.220 --> 04:26.760 Oftentimes there's functionalities we know so correspond to different types of actions to be performed 04:27.060 --> 04:34.170 such as retrieving information about a specific tweet or creating a new blog post based on some data 04:34.380 --> 04:35.920 based on the API. 04:35.940 --> 04:38.160 Of course we've been JS to an object. 04:38.160 --> 04:44.490 We might also want to update the information about an event for example saved on our calendar rap or 04:44.520 --> 04:46.860 maybe delete the appointment altogether. 04:46.860 --> 04:54.200 So as we've said different types of actions to be performed let's talk about request messages and rest. 04:54.210 --> 04:56.880 Let's find out what really works. 04:56.880 --> 05:05.210 So by convention in arrest API the TTP request method that we use will correspond to the kind of action 05:05.330 --> 05:07.570 that we want to perform. 05:07.670 --> 05:14.720 We will use the get method to retrieve a resource the post method to create a new one put or a patch 05:14.750 --> 05:17.320 to update the resource and delete. 05:17.330 --> 05:24.710 Of course to delete a resource where in the context of the rest api the resource represents a data entity 05:24.800 --> 05:28.890 such as as we've said a tweet a blog post a product and so on. 05:28.940 --> 05:32.650 What does the response message look like. 05:32.680 --> 05:39.470 The request and response messages look very similar a response message consists of the following. 05:39.470 --> 05:44.370 First of all we've got a status line which contains the request status code. 05:44.420 --> 05:46.390 Success or Failure. 05:46.400 --> 05:52.330 Then we got the request at airfields which contain again additional information about the request. 05:52.360 --> 05:55.960 Then GMT line and of course an optional message body. 05:56.090 --> 05:58.540 So very very similar. 05:58.610 --> 06:04.650 And this is an example of when each GDP status line we've got the protocol and the version and then 06:04.730 --> 06:07.000 the status quo in this case 200. 06:07.060 --> 06:07.560 OK. 06:07.580 --> 06:08.890 Everything is all right. 06:08.900 --> 06:13.070 Here are some examples of statutes codes on the left and on the right. 06:13.070 --> 06:19.700 We go to five status code groups so we have something very common like 2 and red OK which informs our 06:19.700 --> 06:20.270 client. 06:20.270 --> 06:24.500 The request has being successful then for example after a post request. 06:24.530 --> 06:26.870 Let's say that we've just created a new instance. 06:26.900 --> 06:32.540 OK maybe over a blog post we might get back day details of the same post we've just created. 06:32.540 --> 06:36.350 Ended it well one created code which has SAS Yeah. 06:36.440 --> 06:38.900 They used this as being successfully created. 06:38.930 --> 06:39.620 OK. 06:39.730 --> 06:45.970 Then we might get some AdWords OK like for Android but the request or maybe the forum for not found 06:45.970 --> 06:52.180 that it's pretty come when you know everybody knows for or 4 and on the right we find a five star TOS 06:52.180 --> 07:00.530 called groups because as you might have noticed you know all the codes that are in the 200 okay represent 07:00.750 --> 07:06.800 requests that have been successful that we've got the one on there are information out three hundreds 07:06.800 --> 07:11.870 that are right direction for Android's client errors like for example not found. 07:11.870 --> 07:17.810 Maybe we were just looking for a page that doesn't exist or the five hundreds that are instead server 07:17.870 --> 07:18.220 error. 07:18.260 --> 07:23.750 Like for example you might have seen five or two something like that because maybe the web server like 07:23.750 --> 07:25.550 engine X has been mis configured. 07:25.560 --> 07:32.240 Okay so to wrap it up in a nutshell let's see a couple of examples of requests to an online source RESTful 07:32.240 --> 07:32.630 API. 07:32.700 --> 07:40.400 Okay so for instance we might go to slash products using the get h UDP verb and we might expect to get 07:40.640 --> 07:45.050 at least with all our products in a Jason format. 07:45.050 --> 07:48.680 In this case the status code is going to be to Android. 07:48.690 --> 07:55.390 Okay then we might go to slash products slash 17 for example a primary key. 07:55.580 --> 07:58.120 And if this product exists. 07:58.460 --> 08:05.270 Using to get h DDP verb we might get the details of the product we have primary keys 17. 08:05.270 --> 08:07.940 Of course it's time using the Jason format. 08:07.940 --> 08:12.110 Okay in the status code just as well is going to be most likely to undo it. 08:12.110 --> 08:18.440 Okay then let's say that a product has been maybe suspended or deleted or maybe just doesn't exist. 08:18.440 --> 08:19.070 Okay. 08:19.190 --> 08:26.000 Making a get request to slash products slash a primary key of a product that doesn't exist will result 08:26.000 --> 08:27.050 in an error message. 08:27.050 --> 08:29.720 And of course no product needs status code. 08:29.720 --> 08:33.600 In this case could be for or for not found there. 08:33.620 --> 08:36.190 Let's say we wanted to create a new product. 08:36.200 --> 08:39.020 Okay we might go to slash products. 08:39.020 --> 08:39.610 Okay. 08:39.710 --> 08:43.720 We can use the same endpoints to perform different actions. 08:43.760 --> 08:49.160 As long as we're using of course a different age TTP verb as we're going to see more details of course 08:49.190 --> 08:54.380 as we said we will drive a creation of a new product and days to this go to or one created. 08:54.570 --> 08:56.930 Then let's say we wanted to update a product. 08:56.950 --> 08:57.460 Okay. 08:57.480 --> 09:03.860 We will have to use their put HDTV verb going to the proper you are relevant point. 09:03.860 --> 09:07.400 In this case could be something like Slash products slash 15. 09:07.400 --> 09:13.880 The same pattern if we wanted it we've use to get the details okay but this time we're using the PWD 09:13.910 --> 09:14.450 verb. 09:14.520 --> 09:19.730 Okay so we might get an update to the product ESB primary key 15 to Android. 09:19.750 --> 09:20.320 Okay. 09:20.320 --> 09:25.410 Is status code of course in such cases for both post and put requests. 09:25.500 --> 09:31.460 E if we wanted to create or update a product we would have also to send the details about the product 09:31.520 --> 09:32.960 in the message board. 09:32.990 --> 09:33.870 Okay. 09:33.980 --> 09:36.780 And then if we wanted to delete the same product. 09:36.780 --> 09:45.980 Okay product with a paramedic 15 you will have to goes to slash products slash 15 H DP verb D2 it would 09:45.980 --> 09:52.340 expect of course the deletion of a product the instance with primary key 15 and as status code to 0 09:52.340 --> 09:52.940 4. 09:52.970 --> 09:54.740 No content. 09:55.010 --> 10:00.880 Okay everyone that was ead for this lecture I remember you that as always by the end of each lecture 10:00.910 --> 10:07.870 in the corresponding PDA files you can find several reference links that I really suggest you go and 10:07.960 --> 10:09.260 have a look at. 10:09.290 --> 10:15.220 Okay take your time to properly understand all the concepts that we talking about so that you can feel 10:15.220 --> 10:20.260 confident and really master all these keys that you're going to get out of this course. 10:20.260 --> 10:22.330 So that was it for this lecture. 10:22.360 --> 10:23.530 I hope you enjoyed it. 10:23.530 --> 10:24.750 See you in the next one.