BACKEND

Home › Glossary › Backend· 345 ·

REST

\\rest\\n.

Filed underBackendApisArchitectureFront End

In brief · quick answer

REST (Representational State Transfer) is an architectural style for designing networked applications, primarily APIs. It relies on stateless, resource-oriented communication over HTTP with uniform interface constraints.

§ 1 Definition

REST was defined by Roy Fielding in his 2000 doctoral dissertation. It is not a protocol, a specification, or a standard. It is an architectural style with six guiding constraints. An API that follows all six is truly RESTful. In practice, most APIs called REST are actually REST-ish (HTTP APIs that use REST conventions without fully adhering to all constraints). REST is resource-oriented. Every piece of data is a resource identified by a URL (e.g., /users/42). Clients interact with resources through standard HTTP methods: GET (read), POST (create), PUT/PATCH (update), DELETE (remove). Resources are represented in JSON, XML, or other formats, and the representation contains links to related resources (HATEOAS). The key insight of REST is that the web itself is the world's largest RESTful system.

§ 2 The Six REST Constraints

1. Client-Server: separation of concerns. Clients and servers evolve independently.\n2. Stateless: each request contains all information needed to process it. No client context stored on the server between requests.\n3. Cacheable: responses must explicitly indicate cacheability.\n4. Uniform Interface: consistent API surface with four sub-constraints (resource identification, resource manipulation through representations, self-descriptive messages, HATEOAS).\n5. Layered System: client cannot tell if it is talking directly to the server or through intermediaries.\n6. Code on Demand (optional): servers can extend client functionality via scripts.\n\nMost APIs claiming to be REST skip constraint 4 (HATEOAS) and sometimes constraint 2 (true statelessness). That makes them HTTP APIs, not RESTful APIs.

§ 3 HTTP Methods and Status Codes

REST uses HTTP methods as verbs on resources. GET retrieves a resource (or collection). POST creates a new resource. PUT replaces a resource entirely. PATCH applies partial updates. DELETE removes a resource. Each method has defined semantics for success and error responses. Status codes matter: 200 for successful GET/PATCH, 201 for successful POST (created), 204 for successful DELETE (no content). 400 for bad request, 401 for unauthenticated, 403 for unauthorized, 404 for not found, 409 for conflict, 422 for validation errors, 500 for server errors. Using correct status codes is one of the simplest ways to make your API more usable.

§ 4 REST vs RPC vs GraphQL

REST organizes APIs around resources. RPC (Remote Procedure Call) organizes around actions (e.g., /createUser, /getUserById). GraphQL organizes around queries that clients define. REST's resource model works well for CRUD applications but can struggle with complex, nested data requirements (requiring multiple round trips or custom endpoints). GraphQL solves that by letting clients request exactly what they need in one query. RPC is simpler for action-oriented systems. The choice depends on your application: REST is best for simple, cacheable CRUD APIs over HTTP. GraphQL excels at complex data fetching. RPC suits internal service-to-service communication.

§ 5 Note

Common misunderstanding: REST is not a protocol. It is an architectural style. There is no REST specification document to implement. This means every REST API is slightly different in conventions. Another common mistake: believing that using HTTP methods makes an API RESTful. True REST requires all six constraints, including HATEOAS (hypermedia as the engine of application state). Very few public APIs are truly RESTful. The GitHub API, Stripe API, and Twilio API are all HTTP APIs that follow REST conventions without implementing HATEOAS. They are practical REST, not theoretical REST, and that is fine for most use cases.

§ 6 In code

```http
# Request
GET /api/users/42 HTTP/1.1
Accept: application/json
Authorization: Bearer <token>

# Response
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Alice Johnson",
  "email": "[email protected]",
  "_links": {
    "self": { "href": "/api/users/42" },
    "orders": { "href": "/api/users/42/orders" }
  }
}
```

§ 7 Common questions

Q. What is the difference between REST and a RESTful API?: A. REST is the architectural style. A RESTful API is an API that follows REST constraints. Most APIs called RESTful are actually REST-ish HTTP APIs that follow conventions without full constraint adherence.
Q. Should every API use REST?: A. No. REST is excellent for CRUD resources over HTTP. For action-oriented APIs, real-time communication, or internal service calls, RPC, WebSocket, or message queues may be better choices.
Q. What is HATEOAS and do I need it?: A. HATEOAS means API responses include links to related actions. In practice, most APIs skip it because clients are not generic hypermedia consumers. You probably do not need it.

Key takeaways

REST is an architectural style with six constraints, not a protocol or standard.
Resources identified by URLs, manipulated via standard HTTP methods (GET, POST, PUT, PATCH, DELETE).
True REST requires HATEOAS; most practical APIs are REST-ish HTTP APIs and that is fine.
REST is ideal for CRUD resources over HTTP; GraphQL and RPC suit different use cases.

How Atomic Glue helps

Atomic Glue designs and builds RESTful APIs for web applications that need clean, resource-oriented interfaces. We follow practical REST conventions (resource URLs, proper HTTP methods, consistent status codes, sensible naming) without cargo-culting theoretical purity. Our APIs integrate with any front-end framework and include OpenAPI documentation by default. REST API design is a core offering in our Web Development services. Get in touch to design your API.

Get in touch

# REST

Category: Backend (also: Apis, Architecture, Front End)

Author: Atomic Glue Development Team

## Definition

## The Six REST Constraints

Client-Server: separation of concerns. Clients and servers evolve independently.\n2. Stateless: each request contains all information needed to process it. No client context stored on the server between requests.\n3. Cacheable: responses must explicitly indicate cacheability.\n4. Uniform Interface: consistent API surface with four sub-constraints (resource identification, resource manipulation through representations, self-descriptive messages, HATEOAS).\n5. Layered System: client cannot tell if it is talking directly to the server or through intermediaries.\n6. Code on Demand (optional): servers can extend client functionality via scripts.\n\nMost APIs claiming to be REST skip constraint 4 (HATEOAS) and sometimes constraint 2 (true statelessness). That makes them HTTP APIs, not RESTful APIs.

## HTTP Methods and Status Codes

## REST vs RPC vs GraphQL

## Note

## In code

## Common questions
Q: What is the difference between REST and a RESTful API?
A: REST is the architectural style. A RESTful API is an API that follows REST constraints. Most APIs called RESTful are actually REST-ish HTTP APIs that follow conventions without full constraint adherence.
Q: Should every API use REST?
A: No. REST is excellent for CRUD resources over HTTP. For action-oriented APIs, real-time communication, or internal service calls, RPC, WebSocket, or message queues may be better choices.
Q: What is HATEOAS and do I need it?
A: HATEOAS means API responses include links to related actions. In practice, most APIs skip it because clients are not generic hypermedia consumers. You probably do not need it.

## Key takeaways

REST is an architectural style with six constraints, not a protocol or standard.
Resources identified by URLs, manipulated via standard HTTP methods (GET, POST, PUT, PATCH, DELETE).
True REST requires HATEOAS; most practical APIs are REST-ish HTTP APIs and that is fine.
REST is ideal for CRUD resources over HTTP; GraphQL and RPC suit different use cases.

## Related entries

Last updated June 2026. Permalink: atomicglue.co/glossary/rest