The Restaurant Analogy
How does your web browser actually talk to a server at Google or Netflix to get a webpage? They speak a universal language called HTTP (Hypertext Transfer Protocol). HTTP is a text-based, request-response protocol: one side asks for something, the other side replies. Every interaction on the web — loading a page, submitting a form, streaming a video — is built on this foundation.
The easiest way to understand HTTP is to imagine a restaurant:
- The Client (You): You look at the menu and decide what you want. In the web world, your browser is the client.
- The Server (The Kitchen): This is where the resources (food/data) are kept and prepared.
- HTTP (The Waiter): You can't just walk into the kitchen and grab food. You give your order to the waiter. The waiter takes your specific request to the kitchen and brings the result back to you.
Every time you click a link, your browser sends an HTTP Request (an order) to a server, and the server sends back an HTTP Response (the meal). An HTTP request has three parts: a method (what action to take), a URL (which resource to act on), and optional headers and body (extra instructions and data). The response mirrors this structure: a status code (how it went), headers (metadata about the response), and an optional body (the actual content).
HTTP itself is stateless — each request is completely independent. The server has no memory of your previous requests. This simplicity is what makes HTTP massively scalable, but it also means that features like "staying logged in" require additional mechanisms (cookies, tokens) layered on top.