KAHIBARO
Discord Login Register ☰
☰

2.8. HTTP Requests

Table of Contents

Understanding HTTP Requests

When a browser or mobile app talks to a backend, it sends an HTTP request. As a backend developer, almost everything you do is about receiving, understanding, and responding to these requests.

This chapter focuses only on the request side. Responses, status codes, headers, cookies, and sessions have their own chapters. Here you will learn what exactly a request looks like and how to think about it.

The Big Picture: What Is an HTTP Request?

An HTTP request is a message sent from a client to a server that says:

You can think of it as a formal letter:

Letter ConceptHTTP Request Part
Envelope frontRequest line
Extra notes on envelopeRequest headers
The actual contentRequest body (optional)
Destination addressURL / path + host
Delivery methodHTTP method (GET, POST, …)

The Structure of an HTTP Request

Every HTTP request has three main parts:

  1. Request line
  2. Headers
  3. Body (optional)

The full raw request (as the server sees it) looks like this:

http 
POST /login HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Content-Type: application/json
Content-Length: 45
{"username": "alice", "password": "secret"}

1. Request Line

The request line is always the very first line. It has three pieces:

text 
METHOD PATH VERSION

Example:

http 
GET /products?page=2 HTTP/1.1

The request line must be exactly:
<METHOD> <REQUEST-TARGET> <HTTP-VERSION>
separated by single spaces, one line only.

You will learn methods (GET, POST, etc.) and HTTP versions in separate chapters, so here we only care that:

Request Target: Path and Query String

In the request line, the second part usually looks like:

text 
/path/to/resource?key1=value1&key2=value2

It has two parts:

PartExampleMeaning
Path/products/123Which resource on the server
Query string?page=2&sort=priceExtra parameters to filter/sort/etc.

Some examples:

http 
GET / HTTP/1.1
GET /products HTTP/1.1
GET /products/123 HTTP/1.1
GET /search?q=laptop&limit=10 HTTP/1.1

Headers: Extra Information About the Request

After the request line come headers: each on its own line, in the form:

text 
Header-Name: value

Headers are just key-value pairs that:

Examples:

http 
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Language: en-US,en;q=0.9
Content-Type: application/json
Content-Length: 45

You will learn specific important headers in the dedicated "HTTP Headers" chapter, but as a backend developer you should know:

Visual layout:

http 
GET /example HTTP/1.1        ← request line
Host: example.com            ← headers
Accept: text/html            ← headers
User-Agent: CustomClient     ← headers
                             ← blank line (end of headers)
<no body for GET>            ← body (optional)

The Request Body

The body is optional. Not every request has one.

Typical rules:

The body is where the main data lives, for example:

Example, JSON body:

http 
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 51
{"email": "bob@example.com", "password": "123456"}

The server uses headers like Content-Type and Content-Length to know how to read and interpret the body.

Some common request body formats you will see later:

Content-TypeUsed For
application/jsonAPIs, JavaScript frontends
application/x-www-form-urlencodedSimple HTML forms
multipart/form-dataForms with file uploads
text/plainSimple text payloads

Raw HTTP Request Example in Detail

Let us carefully inspect a complete example.

http 
POST /api/todos HTTP/1.1
Host: api.example.com
User-Agent: MyTodoApp/1.0
Accept: application/json
Content-Type: application/json
Content-Length: 68
{"title": "Finish course", "completed": false, "priority": "high"}

Breakdown:

As a backend developer (for example in FastAPI, Flask, Express, etc.) you will:

URLs vs Paths in Requests

When a browser sends a request, it already knows the full URL like:

text 
https://api.example.com/api/users?page=2

But in the request line, only the path and query appear:

http 
GET /api/users?page=2 HTTP/1.1
Host: api.example.com

The scheme (https) and host (api.example.com) are not part of the path.
They show up in:

So as a backend developer, when you see a request inside your server framework, you usually see:

Example: Comparing Several Request Types

Let us compare how different actions look at the HTTP level.

1. Simple GET Request (no body)

http 
GET /products/42 HTTP/1.1
Host: shop.example.com
Accept: application/json

2. GET with Query Parameters

http 
GET /products?category=books&sort=price_asc HTTP/1.1
Host: shop.example.com
Accept: application/json

3. POST with JSON Body

http 
POST /api/orders HTTP/1.1
Host: shop.example.com
Content-Type: application/json
Content-Length: 82
{"user_id": 123, "items": [{"product_id": 42, "quantity": 2}], "payment_method": "card"}

4. POST with Form Data

http 
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
username=alice&password=secret

How Clients Create HTTP Requests

Different clients build HTTP requests under the hood, but the structure is always the same.

Browser Address Bar

If you type:

text 
https://example.com/products/42

The browser sends something like:

http 
GET /products/42 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

You did not see this raw text, but the browser created it.

`curl` Example

curl is a command line tool. When you run:

bash 
curl -X POST https://api.example.com/login \
  -H "Content-Type: application/json" \
  -d '{"email": "alice@example.com", "password": "secret"}'

It generates an HTTP request like:

http 
POST /login HTTP/1.1
Host: api.example.com
User-Agent: curl/8.0.1
Accept: */*
Content-Type: application/json
Content-Length: 52
{"email": "alice@example.com", "password": "secret"}

JavaScript `fetch` Example

In the browser:

javascript 
fetch("https://api.example.com/todos", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({ title: "Learn HTTP", completed: false })
});

This sends a request similar to:

http 
POST /todos HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 45
User-Agent: Mozilla/5.0
Accept: */*
{"title": "Learn HTTP", "completed": false}

How Servers See HTTP Requests

Server frameworks hide the raw HTTP text and give you a nice interface, but the underlying data is the same.

Example in Python with FastAPI

You do not need to know FastAPI yet. Look only at what you get from the request:

python 
from fastapi import FastAPI, Request
app = FastAPI()
@app.post("/login")
async def login(request: Request):
    method = request.method             # "POST"
    path = request.url.path             # "/login"
    query_params = request.query_params # e.g. {"next": "/dashboard"}
    headers = request.headers           # dict-like of headers
    body = await request.body()         # raw bytes of the body
    # You would then parse JSON, forms, etc.
    return {"ok": True}

Everything comes from the HTTP request:

The Lifecycle of an HTTP Request

Inside the backend, the request usually goes through steps like:

  1. Network stack reads raw bytes from the connection
  2. HTTP parser identifies:
    • Request line
    • Headers
    • Body
  3. Framework converts them into objects:
    • request.method, request.path, request.headers, etc.
  4. Routing decides which handler function to call
  5. Handler reads data from the request and produces a response

You will see these steps again in later chapters about frameworks and routing.

Common Mistakes and Gotchas

As a beginner, watch out for these issues.

Forgetting the Blank Line Before the Body

If you write raw HTTP manually:

http 
POST /data HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 20
{"value": 123}

This is incorrect because there is no blank line before the body.

Correct:

http 
POST /data HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 20
{"value": 123}

Headers and body must be separated by a single blank line.
No blank line means the server thinks your body is part of the headers.

Incorrect Content-Type

If you send JSON but mark it as form data:

http 
POST /api HTTP/1.1
Content-Type: application/x-www-form-urlencoded
{"name": "Alice"}

The server will try to parse {"name": "Alice"} as form data, which fails.

Correct:

http 
Content-Type: application/json

Mismatched Content-Length

If Content-Length does not match the real body size, the server might:

Normally your HTTP client sets Content-Length correctly for you.

Practice: Read and Analyze Requests

To become comfortable, practice by reading HTTP requests and answering:

  1. What method is used?
  2. What resource is requested (path)?
  3. Are there query parameters? Which ones?
  4. Is there a body? What format?
  5. Which headers look important?

Example 1:

http 
GET /search?q=backend+developer&limit=5 HTTP/1.1
Host: www.example.com
Accept: text/html

Example 2:

http 
PATCH /api/users/42 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer abc123
Content-Length: 27
{"email": "new@example.com"}

You will learn how to implement these endpoints in later chapters, but being able to read them correctly is the first step.

Summary

In the next chapters, you will dive deeper into HTTP responses, methods, status codes, and headers, all of which build on your understanding of HTTP requests.

Views: 7

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro
Visitors: 3055 / 24h
Impressum / Imprint
Datenschutz / Data Policy