REST

REST stands for Representational State Transfer. It is an architectural style rather than a protocol, product, or API specification. A resource represents something the application exposes, such as an order, customer, or deployment, and has an identifier such as /orders/123. Clients exchange representations of that resource, often JSON, rather than accessing its internal database structures directly. REST does not require JSON, and an HTTP endpoint is not automatically RESTful.

REST defines client-server separation, stateless interactions, cache constraints, a uniform interface, a layered system, and optional code on demand. Its uniform interface includes resource identification, manipulation through representations, self-descriptive messages, and hypermedia links that guide application transitions. Many production APIs described as REST implement resource-oriented HTTP interfaces without fully implementing hypermedia. Distinguishing the architectural style from common industry shorthand helps avoid treating every JSON API as a complete REST implementation.

In HTTP-based designs, methods communicate operation semantics. GET retrieves a representation without requesting a state change, POST commonly creates a resource or submits processing, PUT creates or replaces the state at a target URI, and DELETE removes the association between a URI and its current functionality. PATCH applies a partial modification. GET is safe and idempotent; PUT and DELETE are idempotent but not safe. Idempotence means repeating the same request has the same intended server-side effect, not that every response must be identical. POST and PATCH are not inherently idempotent.

Statelessness means each request contains the information needed to understand it without relying on server-held client session context from earlier requests. It does not mean the application has no database or persistent resource state. For example, any healthy backend instance can process an authenticated request for /orders/123 by validating its credentials and reading shared durable storage. This reduces dependence on sticky sessions and makes horizontal scaling and instance replacement easier.

In the cloud, an API gateway can provide a managed entry point for routing, authentication integration, throttling, and observability, while functions or containers implement business logic. Amazon API Gateway offers REST APIs and HTTP APIs as distinct product types; either can expose a resource-oriented HTTP interface. Choose between them by required features rather than assuming that a RESTful design requires the product named REST API. API Gateway REST APIs support capabilities such as request validation, usage plans, and stage caching. API keys identify consumers for usage plans; they are not a substitute for authentication and authorization.

REST does not automatically make services loosely coupled or resilient. A synchronous chain of APIs can still propagate latency and failures. Configure bounded timeouts, retry transient failures with exponential backoff and jitter, and avoid blindly retrying non-idempotent operations. For order creation, an application-enforced idempotency key can prevent duplicate orders after a lost response. For long-running work, an API can return HTTP 202 with a status-resource location and process the work asynchronously through a queue.

Caching can reduce latency and backend load, but cache keys and expiration must reflect query parameters, authorization boundaries, and acceptable staleness. Use HTTP cache directives and validators such as ETags where appropriate. Protect traffic with HTTPS, authorize access to individual resources, and preserve compatible API contracts as implementations evolve. REST provides broadly interoperable request-response interfaces, but large resource graphs may require many round trips, and continuous bidirectional communication may be better served by a different interaction model.