REST: Resources, Statelessness, Uniform Interface

REST stands for REpresentational State Transfer and is not a protocol or a standard, but an architectural style for distributed systems. Roy Fielding described it in his dissertation in 2000. An interface is only considered RESTful if it adheres to certain principles. In practice, REST APIs are almost always implemented over HTTP, though REST does not strictly mandate HTTP.

Resources under URLs: the central idea is the resource. Anything that can be named can be a resource, such as a document, an image, or a customer. Each resource is addressed through a unique address (URI/URL), for example /customers/42. Resources are accessed using the standardized HTTP methods, typically GET, POST, PUT, and DELETE.

Representations: the state of a resource at a given point in time is transferred as a representation, consisting of the data and descriptive metadata. Resource and representation are decoupled, so the same content can be delivered in different formats (JSON, XML, HTML, PDF, and others). JSON is the most common format today.

Statelessness (stateless): every request from the client must contain all the information the server needs to understand and process it. The server does not store any session state between two requests, the session state resides entirely with the client. Each request therefore stands on its own.

Uniform interface: this is the core characteristic of REST and rests on four points:

• Unique identification of resources via URIs.
• Manipulation through representations: the client changes the state on the server by sending representations.
• Self-descriptive messages: each message contains enough information to know how it should be processed (for example via the media type).
• Hypermedia as the engine of application state (HATEOAS): the client follows the links the server supplies in its responses.

Client-server separation: the interface (client) and data storage (server) are separated from each other. This allows both sides to evolve independently, as long as the agreed contract (the interface) stays stable. It improves portability and scalability. REST additionally names the principles cacheable (responses mark themselves as cacheable) and layered system (structured in layers).

Why statelessness matters for scaling and security: because the server doesn't need to hold any session state, any request can be answered by any server. This eases load distribution and horizontal scaling (simply add more servers) and makes the system more robust, since no single server holds indispensable knowledge about ongoing sessions. For security, it means every request carries the necessary authorization information itself and is checked individually, rather than relying on a server-side, attackable session context. Overall, these principles favor simple, lightweight, and fast applications.

GET /api/customers/42 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOiJI...

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

{
  "id": 42,
  "name": "Jane Doe",
  "status": "active",
  "links": {
    "self": "/api/customers/42",
    "orders": "/api/customers/42/orders"
  }
}

Stateless GET request: the client identifies the resource via the URL, sends its own authorization, and receives a JSON representation with hypermedia links.

Sources

• REST - Glossary MDN Web Docs
• What is REST? restfulapi.net (REST API Tutorial)