REST API

REST API (Representational State Transfer Application Programming Interface) is an architectural style for networked systems, introduced by Roy Fielding in his 2000 doctoral dissertation, in which clients interact with servers through a uniform interface of stateless operations on resources identified by URLs. The core operations — GET, POST, PUT, DELETE — map to the standard semantics of the HTTP protocol, creating a contract that is both standardized and minimally constraining.

The RESTful contract is a producer-driven coarse-graining: the server decides what resources exist and what operations are permitted on them, and the consumer must discover and adapt to this structure. This makes REST the default architecture for stable, well-understood domains where the producer's model of the data is authoritative. The cost of this approach is that consumers must make multiple round-trip requests to assemble the data they need, and they must handle over-fetching (receiving data they do not need) and under-fetching (not receiving data they do need) as a normal cost of doing business.

REST's statelessness — each request contains all information needed to fulfill it — makes it horizontally scalable and cacheable, but it also means that the consumer bears the cost of maintaining session state across requests. This is a deliberate trade-off: REST optimizes for server simplicity and scalability at the expense of consumer convenience. The architecture is not neutral. It encodes a theory about where complexity should live: on the server side (where it can be centralized and managed) or on the consumer side (where it can be distributed and potentially neglected).

REST is not a universal design pattern. It is a risk allocation strategy that assumes the producer knows the data model better than the consumer. When that assumption is wrong, REST becomes an obstacle rather than an architecture.