Representational State Transfer API

REST resources and the HTTP contract

A Representational State Transfer API is built around resources, each exposed through a stable URL and manipulated with standard HTTP methods. That makes the interface easier to reason about than RPC-style designs because the request describes the target resource and the intended action separately.

This model also encourages a clean separation between resource identity, representation format, and transport semantics. A client can ask for the same resource in JSON or XML without changing the underlying resource model, which helps systems evolve without rewriting every integration.

Why statelessness matters

REST statelessness means each request contains the information needed to process it, rather than relying on hidden server-side session context. In practice, that improves horizontal scaling, simplifies retries, and reduces coupling between client and server instances.

The trade-off is that the client must carry more context, such as tokens, filters, or pagination state, and the server must treat each call as self-contained. That design often fits distributed services well, but it can expose weak assumptions if teams quietly reintroduce server memory, sticky sessions, or implicit workflow state.

Representations, media types, and evolvability

REST is not the same thing as JSON over HTTP. JSON is only one possible representation, and good RESTful design keeps the resource model independent of the payload format. The response body is a representation of state, not the state itself.

That distinction matters when APIs need versioning, interoperability, or long-term compatibility. Consistent use of media types, predictable field naming, and careful evolution of representations help clients survive change without brittle hardcoding.

Security and integration implications

REST APIs are often exposed across trust boundaries, so predictable structure does not automatically mean safe structure. Because resources are addressable and methods are standardised, security depends on strong authentication, correct authorisation, input handling, and careful control of what each representation exposes.

API security failures commonly appear as object-level authorisation mistakes, overexposed endpoints, weak inventory, or abuse of business flows rather than flaws in the REST idea itself. The design style is neutral; the security outcome depends on how rigorously each resource, method, and representation is governed.

Good REST design also helps defenders because it makes APIs easier to inventory, monitor, and test consistently. When endpoints follow predictable conventions, security teams can more reliably map access control, detect anomalous method use, and validate whether a change has altered the intended resource contract.

Risk and Threat Considerations

REST APIs can become high-value attack surfaces when resource naming, HTTP methods, and object references are exposed without equally strong authorisation checks. A predictable interface is useful for integrations, but it also gives attackers a clear path to probe for broken access control, excessive data exposure, and unsafe request patterns.

Failure mechanism: The usual breakdown is not the REST pattern itself, but a mismatch between the resource a client can reach and the resource it should be allowed to use, especially when object IDs, method semantics, or business actions are enforced inconsistently.

Impact: A compromise can reveal sensitive records, allow unauthorised updates or deletions, or let an attacker automate abuse across many endpoints. For API-specific guidance on these failure modes, see the OWASP API Security Top 10.

Related resources from NHI Mgmt Group

• Who should own API workspace cleanup when local and cloud state diverge?
• How should teams govern declarative CLI tools that change API platform state?
• What breaks when API testing does not maintain session state across requests?
• Who should be accountable for shared-state reliability in managed API gateway deployments?