What Is a REST API? A Plain-English Guide

A REST API is a web API that exposes resources — users, orders, articles — each identified by its own URL, and lets clients act on them through standard HTTP methods like GET, POST, PUT, and DELETE, usually exchanging JSON. Every request is stateless: it carries everything the server needs to handle it.

Nearly every app you use today — whether it’s a weather widget, a payment form, or a mobile banking app — talks to a server through one. REST turned out to be the right default for the web, and understanding it unlocks how modern software is actually wired together.

What REST means

REST stands for Representational State Transfer, a term coined by Roy Fielding in his 2000 doctoral dissertation. The name is academic, but the idea is practical, and a handful of core constraints are what make an API “RESTful.”

Those constraints are:

• Stateless — the server doesn’t remember anything between requests. Each request carries all the information needed to handle it. Authentication credentials, for example, are sent with every request rather than stored in a server-side session.
• Uniform interface — resources are addressed by URL, and actions are expressed with HTTP methods. There’s no separate verb vocabulary to learn.
• Client–server — the client and server are separate; the client doesn’t know how the server stores data, and the server doesn’t know how the client renders it.

HTTP methods mapped to actions

REST maps the four standard database operations — create, read, update, delete — onto HTTP methods:

Method	Typical use
GET	Fetch a resource or list of resources
POST	Create a new resource
PUT	Replace a resource entirely
PATCH	Update part of a resource
DELETE	Remove a resource

A request to GET /articles/42 fetches article 42. A request to DELETE /articles/42 removes it. The URL names the resource; the method names the action.

A real request and response

Here’s what an actual REST API exchange looks like. A client requests a user record:

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

The server responds with a JSON body and an HTTP status code:

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

{
  "id": 7,
  "name": "Alice Chen",
  "email": "alice@example.com",
  "createdAt": "2025-03-15"
}

If the user doesn’t exist, the server returns 404 Not Found. If the client isn’t authenticated, it returns 401 Unauthorized. Status codes are how the server communicates the outcome of a request without encoding it in the response body.

Why REST became the default

Before REST, most web services used SOAP — a protocol that wrapped everything in XML envelopes and required a separate description document just to know what calls were available. It worked, but it was heavy and hard to use from a browser.

REST was lighter. It reused HTTP, which developers already understood, and JSON as the data format. A REST endpoint could be called from a browser, a command-line tool, or any programming language with an HTTP library. That simplicity made it the overwhelming default for public APIs and internal services alike.

HTTPS secures the transport layer, encrypting REST traffic the same way it encrypts any other web request.

REST vs GraphQL

GraphQL is the main alternative that has gained significant traction. The key difference is in how you ask for data:

• REST uses multiple endpoints — one per resource type. A page that needs a user plus their orders might require two requests: GET /users/7 and GET /users/7/orders.
• GraphQL has a single endpoint. The client sends a query describing exactly the fields it wants, and the server returns precisely that — no more, no less.

GraphQL solves over-fetching (getting fields you don’t need) and under-fetching (needing multiple round trips), but it adds complexity on the server side and requires a different mental model. REST remains simpler for straightforward use cases and is still more common in practice.

Takeaway

A REST API is a URL-based contract for talking to a server over HTTP. Resources live at predictable URLs, HTTP methods express what you want to do, status codes report the outcome, and JSON carries the data. Once you understand those pieces, you can read API documentation for any service and start making calls. The conventions are remarkably consistent — which is exactly why REST took over.