✦ Web Development with Django Web communication

L3 · Concept 02 · Web Fundamentals

Learn to Read
Web Messages.

HTTP gives browsers and servers a shared language. Learn to recognize a request, a response, and the clues each message contains.

Learning goalRead the essential parts of HTTP requests and responses, distinguish GET from POST, recognize status-code families, and connect a request to a future Django view.

01 Learn02 Inspect in your browser03 Check your understanding

One conversation, two directions

Request and response

The arrows show two different HTTP messages between the browser and server.

Browser

HTTP requestGET /projects/

Server

HTTP response200 OK + HTML

A GET request can ask for HTML, JSON, an image, or another resource. The response status and Content-Type help the browser understand the result.

01 Learn

HTTP is the language of the web

In the previous lesson, the browser found a server. HTTP is the protocol it commonly uses to ask that server for something and receive a response. HTTPS is HTTP protected in transit by TLS; POST alone does not encrypt data. HTTPS encrypts communication while it travels, but by itself does not guarantee that a site is trustworthy.

GET /projects/ HTTP/1.1
Host: example.com
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html

<html>...</html>

A request has a method, a target path, a protocol version, headers, and sometimes a body. A response has a status code, headers, and usually a body. HTTP/2 and HTTP/3 represent messages differently on the network, but these ideas still help you read DevTools.

GET commonly retrieves a resource and should not change server state. Its parameters often appear in the URL. POST commonly sends data for processing and often has a request body, for example when a form creates a project. POST is not the only method that can change state.

↳

Headers and bodies: Headers describe the message. Content-Type: text/html says the body is HTML; Content-Type: application/json says it is JSON. HTTP itself is stateless, so cookies and sessions can help an application remember context; we will return to them in Module 5.

Anatomy of a request and response

GET /projects/ HTTP/1.1
Host: example.com
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html

<html>...</html>

In GET /projects/ HTTP/1.1, GET is the method and /projects/ is the path. Host and Accept are request headers. In the response, 200 is the status code, Content-Type is a response header, and the HTML is the response body.

Status codes are grouped

1xx  information
2xx  success
3xx  redirection
4xx  client error
5xx  server error

You do not need to memorize every code. Learn the categories, then use DevTools and documentation for details. Common examples are 200 OK, 201 Created, 301 Moved Permanently, 302 Found, 400 Bad Request, 403 Forbidden, 404 Not Found, and 500 Internal Server Error.

Django connection

request → URL route → view → response

Later, Django URL routing will select a view. A view can return an HTML page for a GET request or process form data sent with POST.

GET and POST have different jobs

GET

Read or retrieve

Ask for a resource without intending to change server state.

GET /projects/?page=2

Data location: Often URL query parameters; usually no request body.
Possible server effect: Should not change state.
Typical Django use: Display a page or list of projects.

POST

Send data for processing

Submit data that may create a resource or otherwise change state.

POST /projects/

Data location: Often a request body, such as form fields.
Possible server effect: May change state; it is not automatically secure or encrypted.
Typical Django use: Process a form that creates a project.

Method describes intent, not a database command

The HTTP method signals the purpose of a request, not a direct database operation. GET /projects/ asks for a project list. POST /projects/ sends data that may create a project. POST /login/ sends sign-in data, but does not have to create a database record. GET should be for reading; POST may change application state, but does not automatically mean a new database record is written.

HTTPS protects data while it travels. Do not treat GET as HTML-only, POST as automatically safe, or POST data as permanently hidden.

Status-code families

The first digit gives a useful category. Read the specific code when you need more detail.

1xx
InformationalThe request is being handled; beginners will rarely need these codes.
2xx
SuccessThe request succeeded, such as 200 OK or 201 Created.
3xx
RedirectionThe browser is directed elsewhere, such as 301 or 302.
4xx
Client errorThe request has a problem, such as 400, 403, or 404.
5xx
Server errorThe server could not complete a valid request, such as 500.

A status code is information, not a verdict about a person. Inspect the request, response, and server logs when you later debug an application.

HTTP in My Project Hub

These are typical situations for the future Django application, not required responses for every implementation.

200 OKOpening the project list.
201 CreatedCreating a project through an API.
302 FoundRedirecting after a form is processed successfully.
404 Not FoundOpening a project that does not exist.
403 ForbiddenTrying to access something without enough permission.
500 Internal Server ErrorAn unexpected server-side problem.

A common Django form pattern is POST → Redirect → GET: process a form, redirect the browser, then show a page. You will use it later in the Forms and CRUD module.

HTTP detective

What will the browser most likely do after this response?

Read this response before opening the answer.

HTTP/1.1 302 Found
Location: /projects/

A. Show an error because the page does not exist.
B. Send a new request to /projects/.
C. Automatically delete the previous project.

Reveal the answer

B is most likely. Status 302 signals a redirect, and the browser will usually follow the Location header by sending a new request to /projects/.

Read an HTTP message step by step

Read the method and pathThey show what the browser asks for and how it asks.
Read headers as contextHeaders can identify the host, accepted content, content type, caching, and more.
Read the response status firstThe status tells you whether to expect success, redirection, a client problem, or a server problem.

Avoid these shortcuts

POST means encryptedEncryption comes from HTTPS and TLS, not from choosing POST.
Every non-200 status is a failureA redirect can be expected, and 201 can mean a resource was created successfully.

02 Inspect in your browser

Guided Lab — Investigate HTTP in DevTools

Do this in your browser

Build on Concept 01: inspect the details of two requests without sharing private data, cookies, Authorization headers, or session tokens.

Network panel checklist

Browser
└── Developer Tools
    └── Network
        ├── main document
        └── CSS or JavaScript resource

Chrome, Edge, and Firefox call this panel Network. Labels vary slightly. A page can show cached responses, redirects, or a status other than 200.

Compare two safe requests

Record a fresh page loadOpen Network, reload the page, and select its main document.
Inspect the document requestFind Request Method, Status Code, Request Headers, Response Headers, Content-Type, and the Response or Preview tab.
Inspect one linked resourceSelect a CSS or JavaScript request and compare its method, status, and Content-Type with the document.
Keep private headers privateDo not copy cookies, Authorization headers, session tokens, or private form data into notes or Sloby.

↳

Expected observations: document: GET · status · Content-Type CSS or JavaScript: GET · status · a different Content-Type Describe what you observed in your own words. Different pages can have different statuses, redirects, or cache behavior.

When the request details look different

You see a redirectOpen both requests and compare their status codes and Location header without copying private headers.
The response is cachedReload while Network is open; DevTools may also offer a disable-cache option.
You cannot find the bodyUse Response or Preview. Some resources have no useful text body, and some responses are intentionally empty.

↳

In later Django lessons, the same request details will help you understand URL routing, views, forms, redirects, and JSON APIs.

03 Check your understanding

A browser sends GET /missing-page/, but the server cannot find that resource. Which response is most appropriate?

Choose the status that communicates a missing resource.

GET /missing-page/ HTTP/1.1

Build confidence independently

Compare a project list and a project form

Explain how opening a project list differs from sending a form for a new project.

Your goalDescribe a typical GET request for a list and a typical POST request for a form. Name a method, path, headers or body, a plausible response, and how the server participates.

GET /projects/
POST /projects/

Use your browser and your own notes

Progressive hints

Start by deciding whether each request reads a resource or sends data for processing.
For POST, think about form data in a request body; for GET, think about a path and possible query parameters.
Include a status code that would help the browser understand whether the result succeeded or needs attention.

Ask Sloby for one guiding question about GET, POST, or status codes. Do not paste private headers, tokens, cookies, or form data.

Your learning mentor

Create a free account or sign in to get AI guidance while you learn.

Create free account Log in

04 Understanding Check

Create a free account or sign in to receive AI feedback and save your learning progress.