HTTP

HTTP (Hypertext Transfer Protocol) is the foundational application-layer protocol used by web browsers, mobile apps, and backend services to exchange data, HTML documents, JSON payloads, images, and other resources across the World Wide Web.

While lower networking layers handle host addressing (IP) and reliable byte transmission (TCP), HTTP defines the vocabulary, structure, and rules that make distributed web communication possible.

The Client-Server Model

At the heart of HTTP is the client-server model, an architectural pattern where communication is organized into requests and fulfillment:

• The client initiates a request.
• The server receives, processes, and fulfills that request.

This model creates a clean separation of concerns: one machine asks for a resource or action, and another machine handles the computation and returns the result.

Dynamic server roles

A machine’s role is not permanently fixed by its hardware or hostname. Rather, its role is defined by the direction of each interaction:

Remote Procedure Calls (RPC)

In complex distributed architectures, machines do more than just exchange static documents—they often need to invoke logic running on other machines across the network.

A Remote Procedure Call (RPC) is a mechanism that allows a program on one computer to execute code on another machine over a network as if it were a local function call.

HTTP's Position in the Networking Stack

To understand how HTTP carries both web traffic and RPCs, we must look at where HTTP sits in the layered network hierarchy.

HTTP operates at the Application Layer, positioned directly above the Transport Layer (TCP) and Network Layer (IP):

Because HTTP sits on top of TCP, it automatically inherits TCP's reliable, ordered stream delivery. HTTP does not need to worry about dropped packets or out-of-order bytes; instead, it focuses entirely on structuring requests and responses.

The request–response cycle

HTTP structures communication as a strict request-response model. A client sends a message containing request information, and the server returns a corresponding response message:

Each HTTP exchange is self-contained: it carries all necessary routing, metadata, and data required for the server to understand and process the client's intent.

Code sample

// [Path]
const response = await fetch("https://api.example.com/users", {
  method: "POST",                      // [Method]
  headers: {                           // [Headers]
    "Content-Type": "application/json",
    Authorization: "Bearer xyz",
  },
  body: JSON.stringify({ username: "alice" }), // [Body]  ───>  Server
});

const data = await response.json();   // [Body]  <───  Server

Inspecting HTTP Requests in Practice

Because HTTP is a structured protocol, every interaction can be observed directly in real time. Modern web browsers provide built-in developer tools that reveal every HTTP exchange generated by a page.

What browser DevTools provide

Browser developer tools allow you to:

• Observe all outbound HTTP requests made by a webpage (images, scripts, CSS, API calls).
• Identify the exact HTTP protocol version used (e.g., HTTP/1.1, h2 for HTTP/2, h3 for HTTP/3).
• Inspect request and response headers, query parameters, payloads, and timing waterfalls.

Inspecting network activity step-by-step

1. Open Developer Tools: Press F12 (or Cmd + Option + I on macOS) and navigate to the Network tab.
2. Generate Activity: Load or interact with a webpage. Each network request will appear as a row in the waterfall table.
3. Identify Protocol Versions: Look at the Protocol column to see which HTTP version was negotiated.
4. Examine Message Details: Click on any specific request row to inspect its request headers, response headers, status code, and response preview.

HTTP Message Anatomy

When you select an individual request in browser DevTools or inspect network traffic, what does the message look like? HTTP communication consists of two distinct message structures: Requests and Responses.

Request anatomy

An HTTP request includes four core components:

Response anatomy

An HTTP response includes:

Sequence for analyzing an HTTP exchange

When reading or debugging an HTTP exchange, follow this structured sequence:

1. Request URL & Path: Determine where the request is directed.
2. Request Method: Determine what action is being asked of the server.
3. Request Headers: Check authentication tokens, accepted formats, and client metadata.
4. Status Code: Verify whether the request succeeded or failed.
5. Response Headers: Inspect the Content-Type, caching policies, and cookies.
6. Response Body: Parse and validate the returned data payload.

Routes, Endpoints, and HTTP Methods

While the URL path defines the route or endpoint (the location of the resource), the HTTP method (verb) defines the operation the server should perform on that resource.

By pairing the same endpoint with different methods, you can express full CRUD (Create, Read, Update, Delete) operations:

GET     /api/users      ──>  Retrieve all users
POST    /api/users      ──>  Create a new user
GET     /api/users/42   ──>  Retrieve user #42
PUT     /api/users/42   ──>  Update/replace user #42
PATCH   /api/users/42   ──>  Partially update user #42
DELETE  /api/users/42   ──>  Remove user #42

The core HTTP methods

PUT vs PATCH

Both methods modify an existing resource, but they differ in scope:

• PUT replaces the entire resource. If your request body omits a field, that field is erased.
• PATCH applies a partial update. Only the fields included in the body are changed; all other fields are left intact.

Choosing the right method

• Use GET when reading state without causing side effects on the server.
• Use POST when submitting new data that causes the server to create a resource or process an action.
• Use PUT when replacing an existing resource in its entirety with new data.
• Use PATCH when updating only specific fields of an existing resource.
• Use DELETE when deleting a target resource.

Request Bodies, Method Behavior, and Idempotence

Different HTTP methods behave differently with respect to data payloads, server state, caching, and retries.

Request bodies

A request body carries additional data sent with the request. Methods such as POST and PUT regularly include a body (e.g., JSON documents or form data) to provide the necessary payload for creation or updates. Conversely, GET and DELETE requests typically do not carry a body.

Understanding idempotence

A method is idempotent if making multiple identical requests has the same net effect on the server state as making a single request.

GET /item/1  (1x or 100x)  ===> Server state remains unchanged        (Idempotent)
PUT /item/1  (1x or 100x)  ===> Server state set to the same value   (Idempotent)
DELETE /item/1 (1x or 100x)===> Item 1 is removed                    (Idempotent)
POST /items  (1x vs 10x)   ===> Creates 1 item vs creates 10 items   (NON-Idempotent)

Idempotence is a critical concept in distributed system design:

• If a network glitch causes a GET, PUT, or DELETE request to time out, the client can safely retry the request automatically.
• If a POST request times out, retrying blindly could result in duplicate database entries or double-charging a customer's credit card.

HTTP Status Codes

When a server finishes processing a request, it communicates the outcome back to the client using a three-digit HTTP status code.

Status codes are grouped into five standard ranges:

• 1xx (Informational): Request received, continuing process.
• 2xx (Success): The action was successfully received, understood, and accepted.
• 3xx (Redirection): Further action must be taken to complete the request (e.g., URL moved).
• 4xx (Client Error): The request contains bad syntax or cannot be fulfilled by the client.
• 5xx (Server Error): The server failed to fulfill an apparently valid request.

Common status codes

When reading an HTTP response, immediately check the status code range to pinpoint who owns the problem: a 4xx code means the client needs to change its request; a 5xx code means the backend server encountered an internal failure.

Securing the Channel: HTTPS, SSL, and TLS

Plain HTTP transmits all message contents—URLs, headers, authentication cookies, authorization tokens, and request/response bodies—as unencrypted plaintext. Anyone positioned on the physical network path between the client and server (such as an insecure public Wi-Fi network, an ISP, or a compromised router) can inspect or alter the traffic.

HTTPS (Hypertext Transfer Protocol Secure) eliminates this vulnerability by wrapping standard HTTP inside an encrypted security layer using TLS (Transport Layer Security), historically known as SSL (Secure Sockets Layer).

┌───────────────────────────────────────────────────────────┐
│              HTTP Application Data (Plaintext)            │
├───────────────────────────────────────────────────────────┤
│         TLS / SSL Encryption & Authentication Layer       │
├───────────────────────────────────────────────────────────┤
│                   TCP Transport Layer                     │
└───────────────────────────────────────────────────────────┘

The relationship between HTTP, TLS, and HTTPS

• HTTP defines what is being transmitted (requests and responses).
• TLS / SSL is the cryptographic protocol that encrypts and secures the communication.
• HTTPS is standard HTTP data running through a secure TLS connection:

TLS handshake

Before the first HTTP byte is sent over an HTTPS connection, the client and server run a TLS handshake to negotiate a shared encryption key:

1. Client Hello   ──>  Client sends supported TLS versions & cipher suites
2. Server Hello   <──  Server selects version & cipher; sends its certificate
3. Key Exchange   ──>  Client verifies the certificate, derives a session key
4. Finished       ──>  Both sides confirm the handshake; encrypted channel open

Key Takeaways

• Client-Server Architecture: Clients initiate requests; servers fulfill them. In distributed architectures, backend servers frequently act as clients to other servers.
• Remote Procedure Calls (RPC): RPC frameworks allow machines to execute code across a network using application-layer protocols.
• Protocol Layering: HTTP sits at the application layer directly above TCP and IP, structuring data into discrete request-response exchanges.
• Message Anatomy: Requests specify a URL, path, method, headers, and optional body; responses return a status code, response headers, content type, and body.
• HTTP Methods & Idempotence: GET, PUT, and DELETE are idempotent (safe to retry); POST is non-idempotent (creates new state on each execution); PATCH partially updates a resource without replacing the whole record.
• Status Codes: 2xx indicates success, 3xx redirection, 4xx client errors, and 5xx server failures.
• HTTPS Security: HTTPS wraps HTTP in TLS encryption, providing confidentiality, data integrity, and server authentication.