Blog
Long-form behind the videos.No filler, real projects.
Build notes, coding lessons, and honest reviews from the projects behind each video.
Blog
Build notes, coding lessons, and honest reviews from the projects behind each video.
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.
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.
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.
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.
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.
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.