REST (Representational State Transfer)

REST stands for Representational State Transfer and describes an architectural style for distributed systems. Its constraints include a uniform interface, stateless communication between client and server, and rules for caching and system layers. REST is neither a data format nor a separate transport protocol.

REST (Representational State Transfer) explained

A REST-oriented web interface centres on resources, such as a product or document. An address identifies the resource; a representation conveys its current . JSON is one possible format, not a REST requirement. An interface returning JSON over HTTP does not thereby satisfy all REST constraints.

Stateless here means a request contains the information needed for the server to process it, without relying on a previously stored client conversation state. This does not prohibit databases or stored products and orders. The state of a resource differs from conversation state between requests.

In Fielding’s account, a uniform interface involves more than suitable addresses and HTTP methods. It includes self-descriptive messages and links to possible next steps. Everyday use of the REST label is often broader. Check an API’s documented properties instead of inferring its behaviour from the label.

Repetition is particularly important in integrations. An idempotent operation is intended to have the same effect on server state when repeated identically as when performed once. Its responses need not be identical. Whether and how a failed request can be retried depends on the operation and its implementation.

Examples

Hypothetical application

A portal sets the delivery address of a saved draft through a PUT operation implemented accordingly. After a connection interruption, it sends the same request again. The address remains the same. For the subsequent creation of an order, the team separately defines how repeated requests are recognised to prevent a second order.

Key Points

REST is an architectural style with several constraints.
JSON over HTTP alone does not establish REST conformance.
Stateless communication does not prohibit stored resources.
Distinguish repeatable effect from identical response.

Practical application

Check resources, methods, responses, errors and retry rules against the required journey. Then assess whether the interface supports an understandable and reliable integration.

Useful measures

Contract fidelity

Compare documented requests, responses and errors with actual implementation.

Retry behaviour

Check for duplicate or contradictory operations after connection interruptions.

Integration effort

Assess mapping, error handling and later changes across the whole journey.

Common mistakes

Calling every JSON interface fully REST-conformant.
Confusing statelessness with an absence of stored data.
Treating idempotence as a guarantee of identical responses or safe repetition of every operation.

Sources and context

Roy Fielding: Representational State Transfer
Primary source for the REST architectural style and its constraints, including stateless communication and a uniform interface.
MDN: Idempotent
Distinguishes the intended effect of repeated requests from identical responses and explains the role of HTTP methods.

Frequently Asked Questions about REST (Representational State Transfer)

No. REST describes architectural principles; JSON is a data format. A REST interface can use different representations.

Loading related terms…

All Terms

REST (Representational State Transfer)

REST (Representational State Transfer) explained