Django Request-Response Cycle – An easy to follow guide
Django Request-Response Cycle
All backend technologies and web APIs are based on one system that is The Request-Response Cycle. The system is responsible for data interchange between client and servers. Even the new technologies based on micro-services use the Request/Response cycle.
Ready to learn? Let’s get started.
Keeping you updated with latest technology trends, Join DataFlair on Telegram
How does Web Work?
It’s simple yet a very important aspect to understand. So, basically, any application over the internet works by passing information. This information is often passed as objects. The objects mentioned here comprises of various files or properties. These objects can contain files as attachments. It is a very similar concept to emails.
Wait! Have you checked Django Emails Tutorial
These interchanges between various servers and client machines following a set of rules. That set of rules is called HTTP. HTTP stands for HyperText Transfer Protocol. It’s simply a set of rules, a common standard followed by devices to connect to each other over the internet. The information sent or received is given the name of request and response.
Request Objects contain the request made by the client. The server responds with the appropriate information according to Request Object. On the other hand, the Response Object is information served by the server to the client. It all makes sense now? Wait, there’s still more:
The below figure clearly explains how the web works. Well, it does that on a very high-level perspective. In this figure, both the client and server are using HTTP. If both of them don’t have the same protocol, the connection can not be done. Just like humans need to have a common language to understand each other. The same way, various computers and machines over the internet need to have the same protocol. At least the one through which they communicate.
Now, it’s time to understand Request. The requests are smaller in size than response. Basically, a Request is a “request made by the client” to the server. Any URL that gets searched is a request.
But, that’s not the only type of Request. Request objects also give information to the server. The forms we fill, the images we upload to the server are also Requests. When we upload this information, it is transferred as attributes of the Request object.
The server can then access that information and call its own functions.
As you can see in the image, we have a request for http://localhost:8000. From that, we also get a response.
This is the response object we actually get from the server. It has various parts to it. The response object we are discussing has 5 headers. Any response or request objects have a part to them called HTTP headers. These HTTP headers contain various information regarding the response. You can consider it as metadata of response objects. It tells the browser that from where the response came and what type of data it contains. There are many properties in the HTTP header.
So, in the above example response, we can see the Content-Type attribute. That attribute’s values are text/html; charset=utf-8. This means that the response contains an HTML file.
Django Request-Response Cycle
Django’s handling of Http Requests and Response is unique in its own ways.
Django can be considered as an application on the server. Its main task is to process the request received by the server. Then it calls functions and provides a response. This is a brief of how Django interprets Request and provides Response.
Whenever a request comes into Django, it is handled by middlewares. When the Django server starts, the first thing it loads after settings.py is middlewares.
The Request is processed by various middlewares one at a time. So, from the above list, when the request comes it will be passed through the security middleware. If it deems it to be unhealthy, then it will not let the request go any further.
Otherwise, the authentication requests are handled by authentication middleware. That comes after 4 middleware classes that didn’t find how to handle that request.
Once, our request is processed by these middlewares it is passed to the URL Router. The URL router simply extracts the URL from the request and will try to match it to defined urls.
Once, we get a matching URL, the corresponding view function is called. The view function will get various attributes and other URL parameters. Also, the view function will be able to access files from the requests. These Requests are considered to be HttpRequest class objects. The requests module is a Python module that provides various methods for Request objects.
Once, the view function has been executed, it’s time to give a response. The response is given in the form of HttpResponse. The response is not limited to that. The Response can be PDF, JSON, CSV. That is one of the features of Django. It provides built-in support to provide responses of various types. When the response is a render, it will look for the HTML. The HTML page to be the server is processed by Django Templating Engine. Once that completes, the Django simply sends the files as any server would. That response will contain the HTML and other static files.
Let’s take an example in which we will access the request data and print that in the server command line. Ultimately it’s just text.
Here is the view function.
When I run the server and request something in the browser, it will print this information on the command line.
Here, you can see the command line output.
As you can see, there are lots of information for a request like this.
And since it’s also serving an HTML page, you can try these with any of your view functions.
These are the basics of how we can access the request and response objects. Check out our Django CRUD application tutorial for a much better understanding of these methods.
I hope this article on the request and response cycle provided to be useful in your understanding of the Django framework. We understood how Django handles any request coming its way. The request handling of any framework is an important concept. Since we have been implementing the concepts in various projects, we need not develop a new one here. I hope you like this post.
Clear with the Django request and response cycle? Mention your queries & feedback in the comment section.