How REST APIs Work: Architecture Explained for Beginners

Every time a mobile app loads your profile, a website fetches search results, or one service talks to another, a REST API is usually involved. REST is not a product or a language. It is a set of design constraints for how clients and servers exchange data over HTTP.

Developers should understand REST because it is the default style for public web APIs, internal microservices, and most backend tutorials. Once you know how resources, HTTP methods, status codes, and stateless requests fit together, reading a network tab and writing an API client become much simpler.

This guide explains what REST is, how a request travels through the stack, which HTTP pieces matter, and which misconceptions trip beginners up.

Simple Explanation

A REST API treats pieces of data as resources that live at URLs. A user, an order, a blog post, or a product is a resource. The client does not run database queries. It asks the server to perform a standard action on a resource using HTTP:

• GET — read a resource
• POST — create a resource
• PUT or PATCH — replace or update a resource
• DELETE — remove a resource

Think of a library catalog rather than a private conversation. You use a small set of verbs on many named resources. The server decides how those resources are stored. The client only sees URLs, HTTP methods, headers, and a payload (usually JSON).

REST stands for Representational State Transfer. The important word is representation. The server holds the real resource. What travels over the network is a representation of that resource at a moment in time — often a JSON document.

How It Works Internally

A typical REST call looks simple: fetch('/api/users/42'). Underneath, several layers cooperate: client app, HTTP library, TCP/TLS, reverse proxy, API server routing and auth, business logic, then database or other services.

1. The client builds an HTTP request

GET /api/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOi...

The path identifies the resource. Headers describe how to interpret the request. The body is usually empty for GET and DELETE. POST, PUT, and PATCH typically send JSON.

2. DNS, TCP, and TLS happen first

The client resolves api.example.com to an IP address, opens TCP (often port 443), and completes a TLS handshake. REST rides on these layers. Persistent connections and HTTP/2 multiplexing reduce the cost of many small API calls.

3. Routing maps URL plus method to a handler

A router matches method and path. GET /api/users/42 might bind to getUser(id=42). A mismatch produces 404 (unknown resource) or 405 (method not allowed).

4. Middleware runs around the handler

• Authentication — is the caller identified?
• Authorization — is this caller allowed to touch this resource?
• Validation — does the body match the schema?
• Rate limiting — has this client exceeded a quota?
• Logging — request IDs for debugging

If any fail, the handler may never run. The client still receives an HTTP status code and usually a JSON error body.

5. The handler talks to storage

The handler is ordinary application code. It may query a database, call another service, or read a cache. REST does not require a one-to-one mapping from URL to table.

6. The server sends a representation back

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

{"id": 42, "name": "Ada Lovelace"}

2xx means success, 4xx means the client request was rejected, 5xx means the server failed. Clients should branch on status codes, not only on whether JSON parsed.

Statelessness and the uniform interface

Each request contains enough context to be understood on its own. Auth data is sent again (cookie or bearer token) or looked up from a shared store. That is why load balancers can send consecutive requests to different machines. Resources are identified by URIs. Messages are self-descriptive through Content-Type and status codes.

Real-World Examples

User profile. A single-page app calls GET /api/me. The API checks Authorization, loads the user, and returns JSON. The same endpoint can serve a mobile app.

Create order. Checkout submits POST /api/orders. The server validates stock, writes an order, and returns 201 Created with a Location header such as /api/orders/981.

Public and internal APIs. GitHub and Stripe expose repositories and charges as resources. Internally, an order service may call GET /internal/prices?sku=ABC. That is still REST-shaped HTTP.

Code Examples

const express = require("express");
const app = express();
app.use(express.json());
const users = new Map();
users.set("42", { id: "42", name: "Ada Lovelace" });

app.get("/api/users/:id", (req, res) => {
  const user = users.get(req.params.id);
  if (!user) return res.status(404).json({ error: "User not found" });
  res.json(user);
});

app.post("/api/users", (req, res) => {
  const id = String(Date.now());
  const user = { id, name: req.body.name };
  users.set(id, user);
  res.status(201).location("/api/users/" + id).json(user);
});
app.listen(3000);

GET returns 404 when the id is missing. POST returns 201 plus Location.

const res = await fetch("https://api.example.com/api/users/42", {
  headers: { Accept: "application/json" }
});
if (!res.ok) throw new Error("Request failed: " + res.status);
const user = await res.json();
console.log(user.name);

Always inspect res.ok before treating the body as success data.

Common HTTP Status Codes

• 200 OK — GET or PUT succeeded
• 201 Created — POST created a resource
• 204 No Content — success with no body, common for DELETE
• 400 Bad Request — malformed JSON or failed validation
• 401 Unauthorized — missing or invalid credentials
• 403 Forbidden — authenticated but not allowed
• 404 Not Found — no such resource
• 409 Conflict — state conflict such as a duplicate email
• 429 Too Many Requests — rate limit hit
• 500 Internal Server Error — unhandled server failure

REST vs Nearby Ideas

REST is not JSON. JSON is just a common representation. REST is not the same thing as HTTP; HTTP is the transport. REST is not only CRUD: an action such as cancel order can be a sub-resource like POST /orders/981/cancellation. GraphQL lets clients pick fields in one round trip. gRPC uses binary contracts. REST remains common when HTTP caching and simple tooling matter.

Common Misconceptions

JSON over HTTP is not automatically REST. A single POST /api that accepts an action field is RPC wearing HTTP clothing. PUT and POST are not interchangeable: POST is not idempotent; PUT is. Academic REST includes HATEOAS; many production APIs document URLs in OpenAPI instead. Do not expose table names as URLs. Do not return HTTP 200 with an error object; use real status codes.

Best Practices and Key Takeaways

• Name resources with nouns: /users, /orders/981, not /getUser.
• Use HTTP methods for intent. Never mutate data with GET.
• Return precise status codes and a consistent JSON error shape.
• Version only when you must (many teams use /v1/).
• Keep requests stateless. Put auth material on every call.
• Validate input at the edge. Check authorization on the server.
• Document with OpenAPI.
• Paginate and filter before inventing a new protocol.
• Log method, path, status, latency, and a request id.
• Idempotent methods are safer to retry after timeouts.

FAQ

What is a REST API in simple terms?

A web interface where clients create, read, update, and delete resources by sending HTTP requests to URLs and receiving representations, usually JSON, plus standard status codes.

What does REST stand for?

Representational State Transfer. The client transfers a representation of resource state, not the live database object.

Is REST the same as HTTP?

No. HTTP is the transport. REST is a style for organizing resources and operations on top of HTTP.

Why do REST APIs use JSON?

JSON is easy to parse in browsers and backends, readable in logs, and widely supported. REST does not require JSON.

What is the difference between PUT and PATCH?

PUT replaces the resource. PATCH applies a partial update. Omitting a field in PUT is often treated as clearing that field.

Do REST APIs have to be stateless?

Statelessness is a core constraint. Each HTTP request should carry the information needed to authorize and process that request.

How is REST different from GraphQL?

REST typically exposes many URLs and caches per resource. GraphQL typically exposes one endpoint and lets the client specify a query shape.

How do I test a REST API?

Use curl, HTTPie, Postman, or automated tests that assert status codes and JSON fields. Test 401, 404, and validation failures, not only 200.

Related Articles

• How HTTP Works: Request-Response Cycle Explained
• How HTTPS Works: TLS Handshake and Encryption
• How DNS Works: The Internet's Phone Book Explained
• How Cookies and Sessions Work
• How Browsers Render Web Pages

REST is easier once you treat it as HTTP with disciplined resource design. Learn the methods, status codes, and stateless request pattern, and most web backends become readable instead of mysterious.