A URL starts a conversation
Imagine typing a website address into a browser and pressing Enter. The browser does not already know where that site lives. It first needs an address for the server, then it can send a request and process the response.
GET /learn HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: text/html
<html>…</html>The browser is the client: it asks for a page. A web server receives that request and sends a response. Many different clients can ask the same server for pages at the same time.
A domain such as example.com is a memorable name. DNS helps find the matching IP address, which identifies the server on a network. This is simplified: DNS answers may be cached, and DNS does not carry every later HTTP request.
HTTP in one sentence: HTTP is the web protocol used for requests and responses. A browser commonly sends GET when asking for a page. A 200 status means success; 404 means the requested resource was not found. Headers provide extra information, such as the response content type.
<link rel="stylesheet" href="site.css">
<script src="app.js"></script>
<img src="logo.png" alt="Logo">The browser parses the HTML, then requests referenced CSS, JavaScript, images, and other resources. One visible page often requires many network requests.
browser → web server → Django URL routing → view → HTTP responseDjango runs on the server side. It can route a request to a view, use a database when needed, and return an HTTP response — often HTML. Django is one useful backend framework, not a requirement for every website.
Where Django fits in the server-side work
Django works behind the web server after an HTTP request reaches your application.
- HTTP requestThe server passes a request into Django.
- URL routingDjango chooses which view should handle its URL.
- ViewThe view decides what work and response are needed.
- Template / dataA view may render HTML with a template or use models and a database when needed.
- HTTP responseDjango returns a response for the server to send back to the browser.
A Django response does not always need a template or a database. These are tools a view can use when the request needs them.
One concrete example
Follow one request
This is an illustrative story, not a real endpoint you need to test.
https://example.com/projects/- Enter the addressA visitor enters the URL in the browser.
- Find the serverDNS helps the browser find the IP address for example.com.
- Request /projects/The browser sends a GET request for the /projects/ path.
- Let Django handle itAn imagined Django application routes the request, lets a view prepare the page, and returns HTML.
- Render the responseThe browser receives the HTML, requests any linked resources, and shows the projects page.
Later, your My Project Hub will use the same idea: you will run Django locally, define URL routes, and write views that return responses.
Why this matters for Django: Soon you will run a Django server locally, define URL routes, and write a view that returns a response. Knowing the request route makes those steps easier to connect.
The route from URL to page
- Find the serverDNS translates the domain into an IP address so the browser knows where to connect.
- Send a requestThe browser sends an HTTP request, often GET, asking the server for a resource.
- Build a responseThe server — and sometimes Django — prepares a status, headers, and content such as HTML.
- Render and fetch more resourcesThe browser reads HTML, requests linked files, and displays the finished result.
Useful distinctions
- DNS is not the web pageDNS helps find an address. HTTP carries the request and response after the browser knows where to connect.
- A response is more than HTMLA response also has a status code and headers. HTML can then trigger more requests for CSS, JavaScript, and images.
