What is REST API?

REST (Representational State Transfer) is an architectural style for networked applications, defined by Roy Fielding in his 2000 dissertation. In theory the constraints are protocol-agnostic; in practice, a REST API is an HTTP API that models a system as resources identified by URLs and manipulates them through standard HTTP methods, usually exchanging JSON.

The REST Constraints

Client–Server Separation

The client handles presentation; the server handles data and logic. Each side can evolve and be deployed independently as long as the interface holds.

Statelessness

Every request carries everything the server needs to handle it — the authentication token, the resource identifier, the parameters. The server keeps no per-client session state between requests, which is what lets any instance behind a load balancer serve any request and makes horizontal scaling straightforward.

Cacheability

Responses declare whether they can be cached, using headers like Cache-Control and ETag. This lets browsers, CDNs, and gateways serve repeated GETs without touching the origin — one of REST's most concrete practical advantages over RPC-style APIs.

Uniform Interface

Resources are identified by URIs, manipulated through representations (JSON today), and accessed with a small set of methods whose semantics are standardized: GET is safe and repeatable, PUT and DELETE are idempotent, POST is neither. This uniformity is why generic tooling — clients, proxies, API gateways — works against any REST API. (Fielding's full constraint also includes hypermedia links in responses, i.e. HATEOAS, which most real-world APIs skip.)

Layered System

A client cannot tell whether it is talking to the origin server or to a load balancer, cache, or gateway in between. That lets you add layers — TLS termination, rate limiting, caching — without changing clients, keeping the system modular and maintainable.

CRUD Operations

REST APIs typically map CRUD (Create, Read, Update, Delete) onto HTTP methods. For a book store application:

• Create: POST /books to add a new book
• Read: GET /books/42 to view a specific book
• Update: PUT /books/42 to replace it, or PATCH /books/42 to modify fields
• Delete: DELETE /books/42 to remove it

Commonly Used Status Codes

Code	Meaning	Description
200	OK	The request was successfully processed
201	Created	The resource was successfully created
204	No Content	Success with no response body, typical after DELETE
400	Bad Request	The request was malformed or failed validation
401	Unauthorized	Authentication is missing or invalid
403	Forbidden	Authenticated, but not permitted to access the resource
404	Not Found	The requested resource could not be found
429	Too Many Requests	The client has exceeded a rate limit
500	Internal Server Error	An unexpected error occurred on the server

REST vs GraphQL vs gRPC

REST is the default for public, resource-oriented APIs: cacheable, debuggable with curl, and supported by every gateway and tool. GraphQL fits when diverse clients need flexible queries that aggregate many resources in one round trip — typical for mobile apps and backend-for-frontend layers — at the cost of losing HTTP caching semantics. gRPC excels at internal service-to-service calls: binary Protocol Buffers, streaming, and contract-first codegen. These are complements, not rivals; a common 2026 setup is REST at the public edge with gRPC between services.

Whatever style you expose, the edge concerns are the same — authentication, TLS, rate limiting, input validation. Our API security guide covers that checklist in depth, and designing and operating production API platforms is core work for our DevOps engineering team.