HTTP

Even when computers are connected via the internet, if there is no agreement on what format to send requests in and how to respond, communication breaks down. If A sends 'GET /page' and B cannot tell whether that means 'give me this file' or 'execute something', a new communication protocol would have to be designed every time a web server is built. Without standardized request formats, response codes, and metadata delivery methods, it becomes impossible for a single browser to talk to every web server in the world.

In 1989, Tim Berners-Lee at CERN was looking for a way for researchers to share documents. At the time, file transfers relied on FTP or direct access via Telnet, but there was no concept of following links to navigate between documents. HTTP started as a simple protocol for requesting and receiving hypertext -- documents connected by links. HTTP/0.9 had only GET; HTTP/1.0 introduced headers and status codes; HTTP/1.1 added connection reuse and chunked transfer. Later, HTTP/2 handled parallel requests through multiplexing, and HTTP/3 runs on top of QUIC instead of TCP to reduce latency. A simple document-sharing protocol has become the foundation of web APIs, streaming, and real-time communication.

An HTTP request is composed of four main parts: method, URL, headers, and body. The method acts as the verb, as in 'GET /users/1', indicating what action to perform. Headers carry metadata such as content type, authentication tokens, and cache directives. The body carries the actual data to send to the server in POST or PUT requests. The server responds with a status code, headers, and a body. The status code summarizes the result numerically, like 200 OK. 200--299 indicate success, 300--399 indicate redirection, 400--499 indicate client errors (404 Not Found, 401 Unauthorized), and 500--599 indicate server errors. HTTP is stateless. The server does not remember previous requests. Because each request is independent, information that must persist across multiple requests -- such as login state -- must be managed through separate mechanisms like cookies or JWT.

HTTP and HTTPS are nearly the same protocol, but HTTPS adds a TLS layer to encrypt data in transit. HTTP transmits content in plaintext, making it susceptible to eavesdropping and tampering at any point along the network path. Using HTTP alone on the public internet is effectively no longer recommended. HTTP and WebSocket start with an HTTP handshake, but WebSocket then maintains a persistent connection channel where the server can send messages first. With HTTP, the server cannot respond without a request. HTTP and REST are different concepts. REST is an architectural style for designing URLs and methods on top of HTTP, while HTTP is the protocol that carries that design.

Every time you call an API from the frontend using fetch or axios, HTTP is at work. Branching error handling based on status codes, attaching Authorization to request headers, and using multipart/form-data for file uploads are all concrete HTTP operations. On the backend, routers determine handlers by examining HTTP methods and URL patterns. API design principles like 'GET must be idempotent' and 'POST needs duplicate prevention' originate from the semantics of HTTP methods. For network debugging, what the browser DevTools Network tab shows is the raw HTTP request and response. Being able to read at the HTTP level why a request failed, whether headers were set correctly, and whether the response body matches expectations is essential for narrowing down problems quickly.