REST API: The Architectural Style That Shaped the Entire Web

REST shows up almost everywhere on the modern web, yet it is not a protocol. It is an architectural style, and understanding that distinction is the difference between building APIs that scale and APIs that just happen to use HTTP.

What it is

REST, short for Representational State Transfer, is an architectural style for designing networked applications. Roy Fielding described it in his doctoral dissertation in 2000, and it has since become the most familiar way to build web and mobile APIs. The key point is that REST is not a protocol. HTTP is the protocol that transports requests and responses. REST is the set of conventions for organizing how that communication happens.

In a REST API, data is organized into resources. Each resource has an address, typically a URI, and you interact with it using standard HTTP methods. A GET request reads a resource, POST creates a new one, PUT replaces it, PATCH partially updates it, and DELETE removes it. The same path, say /users/42, can mean very different things depending on which method you send. REST leans on the semantics HTTP already provides rather than inventing a parallel vocabulary.

Why it matters

• It is the most widely understood way to build APIs for web and mobile clients. Developers, tools, and frameworks all speak it natively.
• Endpoints are predictable because they combine a resource path with an HTTP method, which makes APIs easier to learn and document.
• REST takes advantage of existing HTTP infrastructure, including status codes, caching layers, proxies, and authentication headers.
• You do not need a special client to call or debug a REST API. A browser, curl, Postman, or any HTTP library will do.
• It is well suited to public APIs that serve many types of clients and partners, since the contract is simple and transport-agnostic.

How it works

Think of REST like a postal system. Every resource, whether it is a user, an order, or a product, has an address. The HTTP method tells the server what you want to do with that resource: fetch it, create it, modify it, or delete it. A client sends a request to an endpoint, the server processes it, and returns a status code, headers, and a representation of the resource, usually as JSON.

An API is considered RESTful when it follows a set of constraints: client-server separation, statelessness, cacheability, a uniform interface, and a layered system. Code-on-demand is optional. Statelessness means each request must carry all the information the server needs to handle it, so the server does not have to remember previous calls. This makes requests easy to route across multiple machines and simplifies horizontal scaling. Caching is built in because REST reuses HTTP cache semantics, so responses can be stored in browsers, CDNs, or gateways to reduce server load and improve latency.