Backend Without HTTP: How Would the Web Work?

Ever wondered what life without HTTP (HyperText Transfer Protocol) would look like?
It would feel like trying to send a letter without a postman — you have a message, but no reliable way to deliver it to the right place.

To truly understand that, we first need to answer a simple question:

What is HTTP?

And no — not the boring “it stands for HyperText Transfer Protocol” answer

In this article, we’ll explore HTTP from a low-level perspective: how it actually works behind the scenes, how requests and responses travel, and what really happens when you type a URL and hit Enter.

How Do Computers Communicate?

Before we understand HTTP (a protocol used to send data on the web), we first need to understand how computers actually communicate.

Imagine you want to send a message from Person A to Person B. There can be two situations:

Both live in the same house
→ Communication is easy and direct.

They live in different houses
→ You need a proper addressing system so the message reaches the correct destination.

Computers work in a very similar way.

In networking, communication also happens in two common scenarios:

1) Devices are in the same network (same local area network / same router)

2) Devices are in different networks (across cities or countries)

To make sure the message reaches the correct device, every device needs an address.

That address is called an IP Address.

👉 Think of an IP address like your house address — it tells the network where exactly to deliver the data.

what makes HTTP unique

there are a lot of things that are great but one thing that i like the most it is stateless. Stateless means that it has no memory of past interactions every request is treated as a new request. It simplify the server architecture by not storing session information. Now you will say how the hell developer handle the state management. I said state will not be managed by the server that does not mean it will not be managed by client also, developer can manage the state by storing all necessary information in cookies, session and tokens.

Client Server model

Http works on client server model, Where client send Http request and server respond with Http response.

Evolution of HTTP

HTTP 1.0: Opened a new connection for each request, leading to inefficiencies.

HTTP 1.1: Introduced persistent connections, allowing multiple requests and responses over a single TCP connection, significantly improving performance. It also added chunk transfer encoding and better caching mechanisms.

HTTP 2.0: Introduced multiplexing, allowing multiple requests/responses over a single connection using binary framing instead of text. It supports header compression and server push.

HTTP 3.0: Built on the QUIC protocol (over UDP) for faster connection establishment, reduced latency, and better packet loss handling. It continues to support multiplexing without head-of-line blocking.

HTTP Request Send By Client

<method> <request-target> <protocol>
<request-headers>
<representational-headers>
<request-body>

Method
it can be GET, POST, PUT etc.

request-target
it can be absolute or relative URL.

protocol
The HTTP version it can be any that we have discussed above like HTTP 1.0,HTTP 2.0 etc.

request-headers
Headers are metadata sent with a request after the start line and before the body. refer the below example.

Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49

representational-headers

Representation headers are sent in a request if the message has a body, and they describe the original form of the message data and any encoding applied. this is very important for the recipient to understand how to handle the body part of the request properly.

Content-Type: application/json

Request-Body
Typically Only PATCH, POST, and PUT requests have a body.

{
  "firstName": "Rohit",
  "lastName": "Giri",
  "email": "[e-mail]",
}

Request body can contain additional information required by the server to process any request.

HTTP Response Send By Server

A wise man said that if you understand the response send by the server you can debug any Http request and response. By the way i said this 😅.

below is the Wireframe of Http response.

<protocol> <status-code> <reason-phrase>
<Response-Header>
<Representational-Header>
<Request-Body>

below is the real example of response Send by Server

HTTP/1.1 201 Created
Content-Type: application/json
Location: http://Arkaai.dev/users/123

{
  "message": "New user created",
  "user": {
    "id": 123,
    "firstName": "Rohit",
    "lastName": "Giri",
    "email": "[e-mail]"
  }
}

Status-Code
It is very important to understand the Status-Code. Http has 5 types of Status code. These codes tell us the result of the request made by the client (browser/app) to the server.

1. 1xx → Informational

Meaning: Request received, processing continues

Used rarely in real websites.

Examples:

• 100 Continue → Server says “ok, send the body”
• 101 Switching Protocols → Upgrading protocol (like HTTP → WebSocket)

2. 2xx → Success

Meaning: Request successfully completed

Examples:

• 200 OK → Request success
• 201 Created → New resource created (mostly in POST)
• 204 No Content → Success but no response body

3. 3xx → Redirection

Meaning: Client needs to take another action / moved

Examples:

• 301 Moved Permanently → URL changed permanently
• 302 Found / Temporary Redirect → temporarily moved
• 304 Not Modified → use cache, no need to download again

4. 4xx → Client Error

Meaning: Problem from client side (wrong request, invalid URL, etc.)

Examples:

• 400 Bad Request → wrong format / invalid data
• 401 Unauthorized → login required
• 403 Forbidden → not allowed even after login
• 404 Not Found → page/resource not found
• 429 Too Many Requests → rate limit exceeded

5. 5xx → Server Error

Meaning: Server failed to process correct request

Examples:

• 500 Internal Server Error → server crashed or bug
• 502 Bad Gateway → server got invalid response from another server
• 503 Service Unavailable → server down / overload
• 504 Gateway Timeout → server didn’t respond in time

Idempotent VS Non-Idempotent

Idempotent methods can be called multiple times with the same result.
Examples (Idempotent methods):

• GET → only fetch data
• PUT → update/replace resource (same data again = same final state)
• DELETE → delete resource (deleting again won’t change more)
• HEAD / OPTIONS → metadata only

Non-idempotent methods that can produce different result on every call.
Examples (Non-idempotent methods):

• POST → creates new resource every time

Options method and CORS workflow

OPTIONS Method: Used to fetch the capabilities of a server for a cross-origin request. Not directly used by developers but seen in browser network tabs as "pre-flight requests".
Same-Origin Policy (SOP): Browsers restrict web pages from making requests to a domain different from their own.
Cross-Origin Resource Sharing(CORS): A security mechanism enforced by browsers to control how web applications interact with resources on different domains.

basically there are two types of request Simple Request and Pre-flighted Request

Simple Request Flow:
Used for methods like GET, POST, or HEAD.
The client sends a request with an Origin header.
The server checks the Origin header against its CORS policy and, if allowed, includes Access-Control-Allow-Origin in the response.
If the header is absent or doesn't match, the browser blocks the response.

Pre-flight Request Flow:
Triggered when conditions like non-simple HTTP methods (e.g., PUT, DELETE), custom headers, or specific Content-Type values are used.
The browser sends an OPTIONS request before the actual request. This inquiry asks the server if the intended method, headers, and origin are allowed.
The server responds with Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Max-Age (to cache pre-flight results).
If the pre-flight request is successful (status 204 No Content), the browser sends the original request.

OPTIONS /resource/foo
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: x-requested-with
Origin: https://arkaai.dev

Example Response of pre-flighted request

HTTP/1.1 204 No Content
Connection: keep-alive
Access-Control-Allow-Origin: https://arkaai.dev
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Max-Age: 86400

HTTP Caching

Purpose: Stores copies of frequently accessed resources to reduce server load and improve performance.

Mechanism: When a client requests a resource, the cache determines if it has a fresh copy. If so, it serves the cached version. If not, it fetches from the server.

Cache Headers

Cache-Control: Primary header for controlling caching behavior (e.g., no-store, no-cache, max-age, public, private).
Expires: Provides an absolute expiration date/time.
ETag: Unique identifier for a resource's content. Used for conditional requests.
Last-Modified: Timestamp of when the resource was last modified.
Conditional Requests: Clients send headers like If-None-Match (with ETag) or If-Modified-Since (with Last-Modified). If the resource hasn't changed, the server responds with 304 Not Modified, telling the client to use its cached version.

Persistent Connections and Keep-Alive

Persistent Connections (HTTP 1.1+): Keep the TCP connection open after a request/response, allowing multiple requests to be sent over the same connection. This avoids the overhead of establishing a new connection for each request.
Connection: keep-alive Header: Instructs the server to keep the connection open.

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Thu, 11 jan 2026 15:23:13 GMT
Keep-Alive: timeout=5, max=200
Last-Modified: Mon, 10 jan 2026 04:32:39 GMT
Server: Apache

(body)

Conclusion

HTTP is not just “a protocol that transfers hypertext” — it’s the core communication language of the web. Every time we open a website, log in, stream content, or call an API, HTTP quietly manages the conversation between the client and the server.

In this article, we didn’t look at HTTP as a textbook definition — we broke it down from the ground up: how computers communicate using IP addresses, how the client-server model works, how HTTP requests and responses are structured, and why status codes are essential for debugging.

We also explored how HTTP evolved from HTTP/1.0 to HTTP/3, and why features like persistent connections, multiplexing, QUIC, and caching matter for performance. Concepts like idempotency help us design safer APIs, and workflows like CORS + preflight requests explain why browsers behave differently than tools like Postman.

Once you understand HTTP deeply, you don’t just use the internet — you understand what’s happening behind it.

And that’s what turns a normal developer into someone who can build, debug, and scale real-world applications confidently. 🚀🔥