REST API

REST (Representational State Transfer) is an architectural style for building networked APIs in which resources are identified by URLs and manipulated through a small fixed set of operations, typically the HTTP methods GET, POST, PUT, PATCH, and DELETE. A REST API exposes the application as a collection of resources that clients read and modify by exchanging representations (most often JSON).

How it works

A REST API models the domain as resources (/users, /orders/42) and uses HTTP verbs to act on them: GET to read, POST to create, PUT to replace, PATCH to partially update, DELETE to remove. Each request is self-contained. Status codes communicate the outcome (2xx success, 4xx client error, 5xx server error).

True REST as defined by Fielding requires hypermedia (HATEOAS): responses include links to related resources, decoupling clients from URL structure.

REST vs GraphQL vs gRPC

• REST. Resource-oriented over HTTP, JSON by default. Cache-friendly, browser-friendly, ubiquitous tooling.
• GraphQL. Query language over a single endpoint. Clients specify exactly the fields they need. Strong for aggregating data across services, weaker for caching.
• gRPC. Binary protocol over HTTP/2, schema defined in protobuf. High performance, strongly typed, suited for internal service-to-service traffic.

Origin

Defined in Roy Fielding's 2000 doctoral dissertation, Architectural Styles and the Design of Network-based Software Architectures. Fielding was one of the principal authors of the HTTP/1.1 specification.