A free video tutorial from Michele Saba
Developer, Instructor, Consultant
Rating: 4.5 out of 5Instructor rating
4 courses
17,263 students

Learn more from the full course

The Complete Guide to Django REST Framework and Vue JS

Build Professional REST APIs and Single Page Applications with Django and Vue JS !

20:55:07 of on-demand video • Updated April 2023

How to build Backend REST APIs with Python & Django
How to use Django REST Framework and Vue JS to create powerful Single Page Applications, similar to those used by Google, Instagram and Twitter
How to build professional Production-Ready REST APIs with Python, Django and Django REST Framework
How to secure the REST APIs you will create with both Token and Session Authentication
All the basics of Vue JS and Vue CLI for creating reactive Components and Single Page Applications
How to create Real-World Single Page Applications with Vue JS and Django
English [Auto]
Hello, developers, and welcome back. You can often hear people talking about rest APIs or restful APIs. What does it mean In the Django Rest Framework Docs, we can find this puzzling quote. You keep using that word rest. I do not think it means what you think it means. And then right below a couple of lines from the core devs. First off, the disclaimer. The name Django Rest Framework was decided back in early 2011 and was chosen simply to ensure the project would be easily found by developers. Throughout the documentation, we try to use the more simple and technically correct terminology of web APIs. 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 Roy Fielding in his doctoral thesis. Fielding is an authority in computer network architecture and he also co-founded the Apache Http Web server, which I'm sure you probably heard about, Right? And by the way, you can find a link to Fielding's dissertation paper, among the other reference links for this lecture. Remember, you can download all the PDFs, all the slides that I'm using from the first lecture of each section. So with rest, Fielding describes a specific architectural pattern for creating web APIs that use Http as their underlying communication protocol, and that must conform to the following criteria. First of all, resources must be accessible via URL endpoints. The API must use the Json or XML as file format. They have to be stateless, which means that basically a request cannot depend on any other request and must use Http verbs to perform actions. Verbs such as get post, put, delete and so on. So if rest is an architectural pattern for creating web APIs that use Http as their underlying communication protocol, and they must use Http verbs to perform actions well, it's pretty important to figure out what a Http really is. Right? And Http stands for Hypertext Transfer protocol. Http 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, though client and server can be anything really. Just think about smart fridges or smart toasters, you know what I mean? So this is a diagram of a request response cycle in Http client and server communicate by sending plain text messages where client sends a request, the server processes a response and then sends it 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 header fields which might contain additional information about the request. Then we have an empty line which signals that the meta information, meaning the information about the request itself has been sent. And then we have an optional message body. This is an example of a request line using the Http get method. Some people call them request start line. Okay. Both are okay to use. We got the method in this case is get. Then we got the Uri, which just basically is the identifier of the resource. The URL in this case is the home page of Google. And then we got the protocol Http and the version 1.1. So far we've seen how web API is exposed a web apps functionalities and components via URL endpoints 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 passed on to the API. Of course, with a Json 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. Http request method that we use will 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 a resource and delete of course to delete a resource where in the context of a 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 a response message look like? 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 header 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 and the version and then the status code in this case, 200. Okay, everything is all right. Here are some examples of status codes on the left and on the right we got the five status code groups. So we have something very common like 200. Okay. Which informs our client the request has been successful. Then, for example, after a post request, let's say that we've just created a new instance, okay, maybe of a blog post. We might get back the details of the same post we've just created and the 201 created code which tells us, yeah, the instance has been successfully created. Okay, then we might get some errors. Okay. Like 400 bad request or maybe the 404 not found. It's pretty common. You know, everybody knows 404 and on the right we find the five status code groups because as you might have noticed, you know, all the codes that are in the 200. Okay. Represent requests that have been successful, then we've got the 100 that are informational, 300 that are redirection 400 client errors, like, for example, not found. Maybe we're just looking for a page that doesn't exist or the 500 that are instead server error. Like for example, you might have seen 502 something like that because maybe the web server like Nginx has been misconfigured. Okay. So to wrap it up in a nutshell, let's see a couple of examples of requests to an online stores RESTful API. Okay. So for instance we might go to slash products using the get Http verb and we might expect to get a list with all our products in a Json format. In this case, the status code is going to be 200. Okay. Then we might go to slash products, slash 17 for example, a primary key. And if this product exists using the get Http verb, we might get the details of a product with primary key 17. Of course, this time using the Json format. Okay. And the status code just as well is going to be most likely 200. Okay. Then let's say that a product has been maybe suspended or deleted or maybe just doesn't exist. Okay. Making a get request to slash products, slash a primary key of a product that doesn't exist will result in an error message. And of course, no product details. Status code in this case could be 404 not found. Then let's say we wanted to create a new product. Okay, we might go to slash products. Okay. We can use the same end points to perform different actions as long as we're using, of course, a different Http verb as we're going to see in details. Of course, as we said, we would have a creation of a new product and the status code 201 created. Then let's say we wanted to update a product. Okay, we would have to use the put http verb going to the proper URL endpoint in this case could be something like slash products slash 15, the same pattern if we wanted it. We used to get the details. Okay. But this time we're using the put verb. Okay. And so we might get an update to the product instance with primary key 15 200. Okay. 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 the product in the message body. Okay. And then if we wanted to delete the same product, okay, product with primary key 15, we would have to go to slash products, slash 15 http verb delete. It would expect, of course, the deletion of a product instance with primary key 15 and as status code two zero for no content. Okay 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. Okay. Take your time to properly understand all the concepts that we're talking about so that you can feel confident and really master all the skills that you're 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.