Http
The Hypertext Transfer Protocol (HTTP) is the application-layer, request-and-response protocol with which web browsers, mobile apps and programs fetch and send resources such as pages, images and data from servers. A client sends a request naming a resource and an action; the server replies with a status code, headers and usually a body. It is the language of the Web and of most modern APIs.
HTTP was created by Tim Berners-Lee at CERN as part of the World Wide Web, proposed in 1989 and first implemented in 1990 and 1991. The earliest version, now called HTTP/0.9, had a single method, GET, and returned only HTML. HTTP/1.0 was documented in RFC 1945 in 1996, adding headers, status codes and content types. HTTP/1.1 followed in RFC 2068 in 1997 and was revised as RFC 2616 in 1999, introducing persistent connections, the mandatory Host header that lets one server host many sites, and caching controls. RFC 2616 was in effect for about 15 years before being split into RFC 7230 through 7235 in 2014 and then replaced by RFC 9110 and 9112 in 2022.
A message is plain text structure: a request line with a method, a target path and a version, then headers, then an optional body. The method states intent: GET retrieves a resource, HEAD retrieves only its headers, POST submits data for processing, PUT replaces a resource, PATCH modifies part of one, DELETE removes it and OPTIONS asks what is allowed. GET is defined as safe, meaning it should not change server state, and PUT and DELETE are idempotent, meaning repeating them has the same effect as doing them once. Those properties let caches, crawlers and retry logic behave sensibly, and ignoring them is a classic bug: an unprotected link that deletes data through GET can be triggered by a crawler or prefetcher.
HTTP is stateless: each request stands alone, and the server keeps no built-in memory of earlier ones. That simplicity lets requests be spread across many servers and cached by intermediaries, but sessions such as a shopping cart or login need extra machinery. Cookies, invented at Netscape in the mid-1990s, are the standard answer: the server sets a small token in a response header and the browser returns it on later requests. Tokens in the Authorization header serve the same role for APIs. The architectural style called REST, described by Roy Fielding, uses HTTP's methods, URLs and status codes as the vocabulary of a service.
The protocol's wire format has been rebuilt twice without changing its meaning. HTTP/1.1 sends one request at a time per connection, so browsers open several in parallel. HTTP/2, standardized as RFC 7540 in 2015 and derived from Google's SPDY experiment, is a binary protocol that multiplexes many requests over a single TCP connection and compresses headers, but a single lost TCP packet still stalls every stream. HTTP/3, standardized as RFC 9114 in 2022, solves that by running over QUIC and UDP, so streams fail independently. Methods, headers and status codes remain the same, so applications mostly continue unchanged while servers and browsers negotiate the best version available.
Beyond web pages, HTTP has become the universal interface of software. Cloud services, mobile back ends and machine-learning model endpoints are typically exposed as HTTP APIs that exchange JSON, and large language model services stream tokens to clients using long-lived responses. Data scientists meet it through libraries such as requests when pulling datasets. Practical pitfalls include treating 200 as proof that an operation did what was intended, ignoring caching headers and rate-limit responses (429), and forgetting that plain HTTP is readable and alterable by anyone on the path, which is the gap that HTTPS closes.
It is worth separating HTTP from the things it is often confused with: HTTP is not the Internet, not the web page language, and not secure by itself. HTML is the document format a server often returns, URLs name the resources, and TCP, or QUIC, carries the messages. HTTP is only the conversation about them: what is wanted and what the answer is.
Read HTTP as the web's question-and-answer grammar: a client names a resource and a verb, the server answers with a numbered status and a body, and everything else (cookies, caching, multiplexing, HTTP/3) is refinement of that same simple exchange that Berners-Lee first sketched at CERN.