Hello, developers, and welcome back. You can often hear people talking about recipes or restful APIs, what does it mean in the jingoist framework talks? We can find this puzzling quote. You keep using that word, reste. I do not think it means what you think it means. And then right below, a couple of lines from the Chordettes. First off, the disclaimer, the name Django Reste framework was decided back in early 2011 and was chosen simply to share. The project would be easily found by developers. Throughout the documentation we try to use the more simple and technically correct terminology of Web API use. The word rest is the acronym of Representational State Transfer. It was conceived and used for the first time by an American computer scientist called Aroy Fielding, and his doctoral thesis Field is in authority in computer network architecture. And he also co-founded the Apache Web server, which I'm sure you probably heard about. Right. And by the way, you can find a link to fill this dissertation paper among the other reference links for this lecture. Remember, you can download all the PDF, all the slides that I'm using from the first lecture of each section. So with Resta, Fielding describes a specific architectural pattern for creating Web APIs that use HDB as their underlying communication protocol, and that must conform to the following criteria. First of all, resources must be accessible via URL and points. The API must use the Jasen or XML as file format. They have to be stateless, which means that basically a request cannot depend on any other requests and must use HTP verbs to perform actions. Verbs such as get post, put, delete and so on. So if reste is an architectural pother for creating webpages that use HTP as their underlying communication protocol and must use HTP verbs to perform actions, well, it's pretty important to figure out what HDB really is. Right. And HDB stands for Hypertext Transfer Protocol. HDB is one of the most important and popular protocols used to transfer information on the Web based on a system of requests and response messages in a typical client server architecture. So the message exchange takes place typically between a browser accessing a web server or a client app accessing a Web API. The client, the server can be anything, really. Just think about smart fridges or smart toasters, you know what I mean? So this is a diagram of request response cycle in HDB client server communicate by sending plain text messages where client sends a request, the server processes a response and that sends its back to the client. What does a request message look like, the request message consists of the following. First of all, a request line that describes the requests to implement. Then we have the request other fields which might contain additional information about the requests. Then we have an empty line which signals that demand information, meaning the information about the request itself have been sent. And then we have an optional message board. This is an example of a request line using the HTP get method. Some people call them request a start line, ok. Both are OK to use. We got the method. This case is get that we got a new array which just basically used it in defiance of the resource. The rule in this case is the homepage of Google and now we got the protocol HTP and the version one point one. So far we've seen our Web expose the web apps functionalities in components via and boyens so that they can then be accessed by external client apps or by other parts of the same Web app. Oftentimes these functionalities will also correspond to different types of actions to be performed, such as retrieving information about a specific tweet or creating a new blog post based on some data based on to the API. Of course, we register an object. We might also want to update the information about an event, for example, saved on our calendar app or maybe delete the appointment altogether. So, as we've said, different types of actions to be performed. Let's talk about request messages and rest. Let's find out how it really works. So by convention in a rest API, the HTP request method that we use, we correspond to the kind of action that we want to perform. We will use the get method to retrieve a resource, the post method to create a new one put or patch to update the resource and delete, of course, to delete a resource where in the context of the rest API, a resource represents a data entity such as, as we've said, a tweet, a blog post, a product and so on. What does the response message look like? A request and response messages look very similar. A response message consists of the following. First of all, we've got a status line which contains the request status, code success or failure. Then we got the request error fields, which contain, again, additional information about the request, then the empty line and of course, an optional message body. So very, very similar. And this is an example of an HTTP status line. We've got the protocol in the version and then the status quo in this case, 200. OK, everything is all right. Here are some examples of status codes. On the left and on the right, we go to five status code groups. So we have something very common, like 200, OK, which informs our client the request is being successful. Then, for example, after a post request, let's say that we've just created a new instance, OK, maybe of a blog post. We might get back the details of the same post we just created. And it was one that created code, which, says Sacia, the instance is being successfully created. OK, then we might get some errors. OK, like four hundred the request or maybe the 404 not found it. It's pretty common. You know, everybody knows four or four. And on the right we find a five status code groups because as you might have noticed, you know, all the codes that are in the 200 OK, a represent requests that have been successful. Then we've got a one hundreds that are informational, three hundreds that are redirection for hundreds, client errors like, for example, not found. Maybe we were just looking for a page that doesn't exist or the five hundreds that are instead server error. Like, for example, you might have seen five or two, something like that, because maybe the Web server like Engine X has been mis configured. OK, and so to wrap it up in a nutshell, let's see a couple of examples of requests. One online source, restfully API. OK, so for instance, we might go to slash products using the get HTP verb and we might expect to get a list with all our products in adjacent format. In this case, the status code is going to be to andred. OK, then we might go to slash products, slash 17, for example, a primary key. And if this product exists using to get a verb, we might get the details of a product with Primary Keat 17. Of course I'm using the Jaiswal. OK, and the status quo just as well, is going to be most likely 200. OK, then let's say that a product has been maybe suspended or deleted or maybe just doesn't exist. OK, making a get request to slash products, slash primary key of a product that doesn't exist will result in an error message. And of course, no product needs status code in this case could be 404 not found. Let's say we wanted to create a new product. OK, we might go to slash products. OK, we can use the same end points to perform different actions as long as we're using, of course, a different HTP verb as we're going to see in details. Of course, as we said, we would have a creation of a new product. And so those go to 01 created. Let's say we wanted to update a product, OK, we would have to use their put it if you were going to the proper Eurail endpoint in this case could be something like flesh products. Zeleznik 15, the same pattern if we wanted it, we've used to get the details, OK, but this time we were using the put verb, OK? And so we might get an update to the product. This primary key 15 200 OK as status code, of course, in such cases for both post and put requests, if we wanted to create or update a product, we would have also to send the details about a product in the message board. OK, and then if we wanted to delete the same product, OK, product with Parametric 15, you would have to go to slash products, slash 15, htp verb delete. It would expect, of course, the deletion of a product Easton's with primary care 15 and as status code to allow for no content. OK everyone, that was it for this lecture. I remember you that as always, by the end of each lecture in the corresponding PDF files, you can find several reference links that I really suggest you go and have a look at. OK, take your time to properly understand all the concepts that we are talking about so that you can feel confident and really master all the skills that are going to get out of this course. So that was it for this lecture. I hope you enjoyed it. See you in the next one.