How the Web Works: Clients, Servers, and HTTP
Every web application is built on a fundamental exchange between two parties: a client and a server. The client is typically a web browser running on a user's device. The server is a remote computer that stores application logic and data. When you type a URL into a browser, your device sends a request across the internet to a server, which processes it and sends back a response. This back-and-forth is governed by the HyperText Transfer Protocol (HTTP).
HTTP is a stateless, text-based protocol. Stateless means each request is independent — the server does not automatically remember previous requests from the same client. Each HTTP message consists of a request line (or status line for responses), headers, and an optional body. Request headers carry metadata such as the type of content the client accepts, authentication tokens, and caching preferences.
HTTP defines several methods that describe the intent of a request. The most common are GET (retrieve data), POST (send new data), PUT and PATCH (update existing data), and DELETE (remove data). These methods form the backbone of RESTful API design, which you will build in later modules.
Responses carry a status code that tells the client whether the request succeeded. Codes in the 200 range indicate success. Codes in the 300 range indicate redirects. The 400 range covers client errors such as a missing resource (404) or unauthorized access (401). The 500 range signals server-side errors. Understanding these codes is essential for debugging web applications.
Modern browsers also implement HTTPS, which wraps HTTP in a TLS (Transport Layer Security) layer. This encrypts the data in transit, protecting users from eavesdropping and tampering. Any production web application must use HTTPS — browsers now actively warn users when a site does not.
The URL (Uniform Resource Locator) is the address used to locate a resource. It consists of a protocol (https://), a domain name (example.com), an optional port number, a path (/products/shoes), and optionally query parameters (?color=blue) and a fragment (#section2). Learning to read and construct URLs precisely is a basic but critical skill for full-stack developers.
Consider a shopper visiting an e-commerce website. When they click on a product, the browser sends a GET request to a URL such as /products/42. The server looks up product 42 in its database and sends back an HTML page (or JSON data) with a 200 OK status. If the product has been removed, the server returns a 404 Not Found. If the shopper submits a purchase form, the browser sends a POST request containing the order details in the body. This simple exchange — request and response — underpins every interaction on the web.
- The web operates on a client-server model where browsers make requests and servers return responses.
- HTTP is stateless and text-based; HTTPS adds encryption via TLS for secure data transmission.
- HTTP methods (GET, POST, PUT, DELETE) describe the action being requested.
- Status codes (200, 404, 500) communicate the result of each HTTP transaction.
- URLs are structured addresses consisting of protocol, domain, path, query parameters, and fragments.