What Is a REST API?

A REST API is a standardized way for software systems to talk to each other over HTTP, using a small set of verbs (GET, POST, PUT, PATCH, DELETE) and URLs that name the data you want to read or change. REST stands for Representational State Transfer — an architectural style, not a protocol or a library, so any language with an HTTP client can call a REST API.

How a REST API works

The core idea is that everything is a resource (a user, an order, a booking) addressed by a URL, and HTTP methods describe what you want to do with it. The method carries the intent; the URL carries the identity.

The server answers with a status code (200 OK, 201 Created, 404 Not Found, 401 Unauthorized) and usually a JSON body. Two properties make this style hold together:

• Stateless — each request carries everything the server needs (auth token, parameters). The server keeps no per-client session between calls, which makes the API easy to scale horizontally.
• Uniform interface — the same handful of verbs work across every resource, so once you understand one endpoint you understand the shape of all of them.

A concrete request

Reading a single booking looks like this:

GET /bookings/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>

Response:

{ "id": 42, "guest": "Mara", "checkIn": "2026-07-01", "nights": 3 }

Creating one is the same verb-and-URL logic with a body: POST /bookings carrying the new record, answered with 201 Created and the saved resource.

When to use REST (and when not to)

REST is the sensible default for most web and SaaS backends. Reach for it when:

• Many different clients (browser, mobile app, CLI, webhooks) need to hit the same backend.
• You want responses to be cacheable — a GET can be cached by a CDN or browser.
• You value something simple to document, test in Postman, and reason about.

Consider an alternative when REST starts to strain:

• GraphQL when clients need precise control over which fields come back, or when over-fetching across many screen types becomes a real cost.
• gRPC / WebSockets for low-latency service-to-service calls or live, push-style updates that request/response REST handles awkwardly.

For most early-stage products, REST ships faster and is easier to maintain — the more advanced options solve problems you may not have yet.

Common mistakes

• Verbs in the URL — POST /createUser or /getUser?id=42. The method already says the action; the URL should name the resource (/users, /users/42).
• Ignoring status codes — returning 200 OK with {"error": ...} inside hides failures from clients and monitoring. Use the right code (400, 401, 404, 500).
• Skipping authorization at the data layer — checking permissions only in the UI. A REST endpoint is callable directly, so access rules must live on the server.
• Unbounded list endpoints — GET /users returning every row. Paginate from day one.

You often don't have to hand-write one

Tools like Supabase read your Postgres schema and generate REST endpoints for every table automatically. Paired with row-level security (RLS), you get an access-controlled REST API without writing handlers by hand — the approach behind work like Pizzeria Bestek (React + Supabase). The REST concepts above still matter: they're what you're configuring, even when the boilerplate is generated for you.

Key takeaways

• A REST API exposes data as URL-addressed resources and uses HTTP verbs to read and write them.
• It's stateless, cacheable, and callable by any HTTP client — which is why it's the default for SaaS backends.
• Choose GraphQL or gRPC only when REST's simplicity stops paying off for your specific data or latency needs.
• Enforce auth and pagination on the server; the client can always be bypassed.