What constraints define REST, and what does the uniform interface require?

REST (Representational State Transfer) is an architectural style for distributed hypermedia systems, defined by Roy Fielding in his 2000 dissertation. It is not a wire protocol, a file format, or another name for "JSON over HTTP". HTTP is the protocol most REST APIs use; REST is the set of constraints that shaped the modern web.

Fielding derives REST by adding constraints. Applied together they favour scalability, a general interface, independent deployment, and intermediaries:

1. Client-server. User interface and data storage are separated so each can evolve independently.
2. Stateless. Each request must contain all information needed to understand it. Session state is kept on the client, not as hidden server context between requests.
3. Cache. Responses are labelled cacheable or non-cacheable so a client or intermediary can reuse a response for a later equivalent request.
4. Uniform interface. This is the constraint that most clearly distinguishes REST from other network styles. It has four interface constraints of its own: identification of resources; manipulation of resources through representations; self-descriptive messages; and hypermedia as the engine of application state (HATEOAS).
5. Layered system. A component cannot see beyond the immediate layer it talks to, which allows proxies, gateways and shared caches.
6. Code-on-demand (optional). A client may be extended by downloading and running code.

The uniform-interface trade-off is explicit: a standardized form improves visibility and evolvability, but it is less efficient than an application-specific interface. REST optimises for large-grain hypermedia transfer, not for every kind of remote call.

The key abstraction is a resource: any information that can be named. A resource is a conceptual mapping over time, not the bytes stored at a given instant. HTTP uses the same idea. The target of a request is a resource, usually identified by a URI. A representation is information intended to reflect a past, current or desired state of that resource, plus metadata such as a media type. Clients do not receive "the resource itself"; they send and receive representations. HTTP is defined as a stateless protocol: each request's semantics can be understood in isolation.

HATEOAS in practice. Fielding's fourth uniform-interface constraint is that the next steps a client can take should be discovered from the representations it already has (links, forms and other hypertext controls), not from out-of-band path construction alone. Most production HTTP APIs, including most microservice APIs, stop at Richardson maturity level 2: resources, HTTP methods and status codes, with URIs known from documentation or an OpenAPI file. They do not drive the client through hypermedia. That is a deliberate, common engineering choice, not a claim that those APIs satisfy every REST constraint.

Zalando's public guidelines are explicit about this. Teams must use REST maturity level 2 and may use maturity level 3 (HATEOAS). Where links are used, the guidelines require common hypertext controls, prefer simple controls for pagination and self-references, and require full absolute URIs.

Alternate interview scenarios