#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.

#Caveats

REST does not require JSON, and it does not mandate a single naming convention. Many APIs that call themselves RESTful are really just using HTTP to invoke remote functions. Noun-based plural paths like /users are a common best practice, but they are convention, not law. REST can also over-fetch data, require many round trips for related resources, and it was never designed for bidirectional realtime communication. For flexible client querying, GraphQL is often a better fit. For high-throughput internal calls, gRPC wins. For realtime two-way channels, WebSocket is the answer.

#Who it's for

REST is for teams building public, resource-oriented APIs that need to serve a variety of clients, from browsers to mobile apps to third-party partners. If your domain naturally models things as resources and you want an API that is easy to consume, debug, and cache without special tooling, REST remains the default choice.

REST is not the answer to every problem, but for public resource APIs it is still the most pragmatic starting point. Clear resources plus correct HTTP semantics get you most of the way there.

Source: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm