What REST Is and Why It Won

I've been working with APIs for years, but I recently went back to understand REST from first principles. When you use a weather app to check the forecast, something interesting happens behind the scenes. The app sends a request to a server, the server fetches the data, and it sends back the forecast for your location. This exchange happens through an API, a set of rules that lets software applications talk to each other.

That sounds simple enough. But how do the client and server actually communicate? Many standards have been proposed over the years, but REST emerged as the dominant approach for building networked applications. I wanted to understand why.

REST stands for Representational State Transfer. It's not a protocol or a standard but an architectural style, a set of constraints and guidelines for designing web services. APIs that follow these constraints are called "RESTful" and are designed to work with HTTP, the protocol that powers the web.

What makes REST different from earlier approaches is its simplicity. Instead of inventing new protocols, REST leverages what HTTP already provides: URLs to identify resources, standard methods to act on them, and status codes to communicate results.

Where REST Came From

Roy Fielding introduced REST in his 2000 doctoral dissertation at UC Irvine. Fielding wasn't working in isolation. He was one of the principal authors of the HTTP specification, so he understood the web's underlying architecture better than almost anyone.

His insight was that the web itself demonstrated a successful architectural style. Web pages work because they follow certain principles: each page has a unique URL, requests are self-contained, and responses can be cached. Fielding formalized these patterns and showed how they could apply to APIs.

The Six Principles

REST is built on a set of guiding constraints. Understanding these helped me see why certain API designs feel right and others feel awkward.

Stateless. Each request from a client must contain everything needed to process it. The server doesn't store session information between requests. This simplifies server design and improves reliability.

Client-Server. There's a clear separation between the client (which handles the user interface) and the server (which manages data and logic). Either side can evolve independently as long as the interface between them stays consistent.

Cacheable. Responses from the server can be cached by the client. When a resource hasn't changed, the client can reuse its cached copy instead of making another request. This reduces load on the server and speeds up the client.

Uniform Interface. RESTful APIs use a consistent set of URLs and HTTP methods. Once you understand how one resource works, you can predict how others will behave. This predictability makes APIs easier to learn and use.

Layered System. The architecture can include intermediate layers, such as load balancers, caches, or security gateways, between client and server. The client doesn't need to know whether it's connected directly to the server or going through intermediaries.

Code on Demand (optional). Servers can extend client functionality by sending executable code, like JavaScript. This constraint is optional and rarely used in practice.

These constraints work together. Statelessness enables caching. The uniform interface enables intermediaries. The layered system enables scaling.

In the next post, I'll get into the practical mechanics: how resources work, what URLs look like, and how HTTP methods map to operations.