REST (Representational State Transfer) is an architectural style for distributed systems, defined by Roy Fielding in 2000. It is a set of constraints, not a protocol or a standard.
Six constraints define the style:
Client-server: the two sides evolve on their own.
Stateless: each request carries everything the server needs.
Cacheable: responses must say if they can be stored and reused.
Uniform interface: one consistent way to address and act on resources.
Layered system: a client cannot tell if it talks to the origin server.
Code on demand (optional): the server may send runnable code, like JavaScript.
Every request stands alone, as this one does:
GET /articles/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>
Accept: application/json
Statelessness is the main trade-off. Any server node can handle any request, but each call must resend auth and context.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
REST is constraints, not JSON over HTTP: address resources, let methods decide the action, send hypermedia links to what's next and more.
For this question · all 3 chaptersThree things: five constraints define REST, resource naming and hypermedia.
1/3REST is a set of constraints
REST is a set of constraints
Ask an engineer what REST is and you usually get a tool list: JSON, HTTP verbs, a URL scheme. That list cannot tell a RESTful API apart from any other API that sends JSON.
REST is a set of constraints. First is client-server: the client owns the interface, the server owns the data. Next is Stateless which means every request has everything the server needs to answer it. So any instance behind the load balancer can take the next request.
Next is Cacheable. It means a response indicates whether a client or a proxy may keep a copy, so repeated reads never reach your server. Then, Uniform interface - it refers to the shape and structure: resources at addresses, standard methods, and links in the response.
Layered system is the fifth constraint. A client cannot tell whether it is talking to the origin server, a cache, or a load balancer in front of that server. This is REST - all these five constraints combined.
Assume a design broke one of these constraint. For example - a WebSocket connection holds session state on the server between messages, to know which client is connected, and what that client last saw. A request on that connection no longer carries everything needed to answer it, so its no longer stateless.
So you gave up the stateless constraint to keep the connection open. The other four are still good, and the design is right for the use case. WebSockets are the right call for a live chat feed.
Even though four of the constraint are still good, and the API still sends JSON over HTTP. This is a WebSocket design, not REST.
Six endpoints become four addresses
What does 'the uniform interface' mean. The six POST endpoints on the left are each named after an action, so this API ignores the uniform interface. Every feature got its own name, which felt natural but has a cost - growing and unpredictable list of endpoint names.
Instead, name the thing and you got one address, /users/123. The three user endpoints become methods on that address: GET reads the user, PUT replaces the user, DELETE removes the user. Six endpoints will become three, all on that one address. The method specify the action, and the URL is the name of the resource.
The collection for the item is the same noun, plural - /users. Finding a user by email is not a different action. That search is a filter on the collection, GET /users?email=. The collection is just one address, and you can add as many filters later.
Orders belong to a user, so /users/123/orders sits one level under /users/123 and allows GET and POST actions. The path defines who owns what. The left column, the list of actions, is empty now. Every action has an address and a method.
But be careful of nesting. The path /users/123/orders/456/items/7 repeats ids that already identify things on their own. With nesting , it's important to know where to stop. An order has its own id, so /orders/456 stands alone and items sit under that path. So usually, nest one level to show ownership, and stop there.
The address tree should read like the domain: users have orders. And a client should be able to guess addresses that match your entities. A verb in a path means you are calling a function over HTTP, not addressing a resource.
Links tell the client what it may do next
One constraint is still missing, and this is not commonly implemented in practice: the uniform interface also asks for links in the response. Two clients load the same order, status pending. Client A has a map of URLs and and got the Cancel and Pay buttons from that map. Client B relies on links in the response and has got nothing yet, as nothing in the response said what Client B may do.
The server adds a _links block with cancel and pay, then sends the value to client B. Client B reads the links and got two things it can do next, Cancel and Pay. Sending the links with the value is HATEOAS, hypermedia as the engine of application state. The order's state decides which links appear, and those links decide what the client offers.
The order is paid, so the response says paid and the links say refund. The new value reaches Client B. Client B stops getting Cancel and Pay and got Refund instead, with no code change. Client A still got Cancel and Pay, because its map from state to buttons does not know the order is now paid.
Client A sends Cancel from its own map of URLs and gets a 409. Client B sends Refund from a link the server sent and gets a 200. B never built a URL and never offered an action the server had not offered first, so the server can move URLs and rules without breaking B.
Client A keeps working without the links, but client B has nothing left to display. So why does almost nobody ship hypermedia? Most APIs stop at level 2 of the Richardson model: resources and methods, URLs in the docs and the SDK, no links in the body. Level 3 adds the links.
A generated SDK fails the build when a URL moves. The build failure is the protection level 3 would have given at runtime. Most teams make that trade on purpose: an HTTP API at level 2. They instead use OpenAPI spec to publish their URL map.
Chapter 1 · step 1 of 7
Ask an engineer what REST is and you usually get a tool list: JSON, HTTP verbs, a URL scheme. That list cannot tell a RESTful API apart from any other API that sends JSON.
REST is a set of constraints, and dropping one means you cannot call your API REST. In practice the uniform interface means addresses for things and methods for actions. Addresses nest one level deep to show ownership. Hypermedia is the constraint many APIs skip on purpose, so strictly speaking its an HTTP API at level 2.
If REST is stateless, how does a logged-in user stay logged in?Each request carries a token the server can verify. Say why server-side sessions break the rule and what a shared session store costs.
How does the cacheable constraint show up in real HTTP responses?Cache-Control and ETag headers, conditional GETs that return 304, and why GET responses cache while POST responses usually don't.
Is REST tied to HTTP? Could you build a RESTful system on another protocol?REST is a style and HTTP is one protocol that fits it well. The constraints never name HTTP, though almost every real REST API uses it.
REST is an architectural style that Roy Fielding defined in 2000. It's a set of constraints, not a protocol or a standard.
Client and server are separate so each can evolve on its own, and every request is stateless, meaning it carries everything the server needs.
Responses have to say whether they can be cached, and a uniform interface gives you one consistent way to address resources and act on them.
It's a layered system, so a client can't tell if it's talking to the origin server or something in between, and code on demand, like sending JavaScript, is the one optional constraint.
So a request like GET /articles/42 with a bearer token and an Accept header stands on its own.
Statelessness is the main trade-off. Any server node can handle any request, which makes scaling out simple, but every call has to resend auth and context.
Weak answers to avoid
Says REST means JSON over HTTPREST is a set of constraints, not a format or a protocol. Name the constraints and treat JSON and HTTP as common choices, not the definition.
Lists CRUD verbs instead of constraintsMapping GET, POST, PUT and DELETE to CRUD is one slice of the uniform interface. Name the constraints and say what statelessness costs.
Confuses stateless with no stored dataStateless doesn't mean no database. It means the server keeps no client session between requests, so each request carries its own auth and context.
Recites six names with no trade-offA memorized list sounds rehearsed. Tie at least one constraint to a consequence, like statelessness letting any node serve any request.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
