Understanding HTTP

When I first started building web applications, HTTP felt invisible.

I was calling APIs, sending requests, getting JSON responses, and everything just worked. But I didn’t really understand what was happening under the hood. It felt like magic.

At some point, that stopped being enough.

If you want to become a strong backend developer, you need to understand HTTP deeply—not just what it does, but how it works from first principles.

So I decided to break it down completely.

This blog is that breakdown.

The First Principle: What is HTTP?

HTTP stands for HyperText Transfer Protocol.

At its core, HTTP is just a communication protocol. It defines how a client and a server talk to each other.

It tells us:

• how to structure a request
• how to structure a response
• how data should be transferred

That’s it.

The Core Mental Model

Every HTTP interaction follows a simple pattern:

1. The client sends a request
2. The server processes it
3. The server sends a response

That is the entire web.

What Happens When You Open a Website

Let’s say you type:

https://example.com

Behind the scenes:

1. The browser finds the server (DNS resolution)
2. A connection is established (TCP)
3. The browser sends an HTTP request
4. The server sends back an HTTP response
5. The browser renders the page

HTTP is responsible for step 3 and 4.

HTTP is Stateless

HTTP is a stateless protocol, which means:

• Each request is independent
• The server does not remember previous requests

Example:

GET /profile
GET /profile

Both requests are treated separately.

HTTP Message Structure

Request

GET /api/users?id=1 HTTP/1.1
Host: example.com
User-Agent: Chrome
Accept: application/json

(body)

Response

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 120

(body)

Each message consists of:

• Start line
• Headers
• Body

HTTP Methods

Methods define the action:

• GET → retrieve data
• POST → create data
• PUT → update data
• DELETE → remove data
• OPTIONS → check allowed operations

Idempotency and Safety

• Safe → does not modify server (GET)
• Idempotent → same result every time (GET, PUT, DELETE)

HTTP Status Codes

Status codes indicate the result:

• 1xx → Informational
• 2xx → Success
• 3xx → Redirection
• 4xx → Client Error
• 5xx → Server Error

Examples:

• 200 OK
• 201 Created
• 404 Not Found
• 500 Internal Server Error

HTTP Headers

Headers are metadata:

Content-Type: application/json
Cache-Control: max-age=3600
Authorization: Bearer token

They control:

• format
• caching
• behavior

Content Negotiation

Client specifies preferred format:

Accept: application/json

Server responds accordingly:

Content-Type: application/json

HTTP Caching

Caching stores responses to improve performance.

Cache-Control: max-age=3600
ETag: "abc123"

Validation:

If-None-Match: "abc123"

Response:

• 304 → use cache
• 200 → new data

CORS

CORS controls cross-origin requests.

Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Allow-Methods: GET, POST

If not allowed → browser blocks request.

OPTIONS Method

Used for preflight requests:

1. Browser sends OPTIONS
2. Server responds with rules
3. Actual request is sent

Connection Management

Connection: keep-alive

Reuses connections → better performance.

HTTP Versions

• HTTP/1.1 → basic, keep-alive
• HTTP/2 → multiplexing
• HTTP/3 → QUIC (faster, UDP-based)

Payload and Encoding

Common types:

• application/json
• text/html
• multipart/form-data

Content-Length vs Chunked

• Content-Length → fixed
• Chunked → streamed

URL Structure

https://example.com/api/users?id=10

Parts:

• protocol
• host
• path
• query

Redirection

• 301 → permanent
• 302 → temporary
• 307 → method preserved

Proxies

• Forward proxy → client side
• Reverse proxy → server side

Used for caching and load balancing.

Putting It All Together

A typical flow:

1. Client sends request
2. Headers define behavior
3. Server processes
4. Server responds
5. Status code indicates result
6. Headers control caching and format

What I Learned

HTTP is not just a protocol.

It is a system that combines:

• communication
• structure
• performance
• scalability

Once I understood HTTP deeply, everything started making more sense:

• API design
• debugging
• frontend-backend interaction
• performance optimization

Conclusion

HTTP is the foundation of the web.

Understanding it from first principles removes the “magic” from web development and replaces it with clarity.

If you understand HTTP, you understand the web.

References

• RFC 7231
• MDN Web Docs
• HTTP/2 Specification
• HTTP/3 Specification