REST API — What It Is and How It Works

The fastest way into REST is to stop thinking about actions and start thinking about things. A study app does not really have a "grade this answer now" command — it has problems, students, and attempts. Once you see the system as a set of nouns, each with its own address, the rest of REST mostly falls out of that one shift.

A REST API is a common way to design a web API around resources such as users, problems, or orders. Each resource gets a URL, and HTTP methods such as GET, POST, PATCH, and DELETE tell the server what the client wants to do. REST stands for Representational State Transfer: a client sends an HTTP request, the server returns a representation of a resource, and each request should make sense on its own. Many REST APIs return JSON, but JSON alone does not make an API RESTful.

Resources Are Nouns, Methods Are Verbs

If your system has problems, students, and attempts, those are resources, with URLs such as /api/problems/42 or /api/attempts/9001. The HTTP method then says what kind of operation is happening:

• GET reads a resource
• POST creates a new resource
• PUT replaces a resource
• PATCH updates part of a resource
• DELETE removes a resource

That separation is what makes REST easy to scan. The URL says what you are working with; the method says what you want to do.

How a Request Actually Flows

A browser, mobile app, or another service sends a request containing a URL, an HTTP method, optional headers, and sometimes a body. The server reads it, performs the action, and returns a response — usually a status code such as 200 OK, 201 Created, or 404 Not Found, plus data describing the result.

One important condition is statelessness: each request should contain the context needed for that request. That does not mean the server stores no data. It means the server should not need hidden conversation state from earlier requests to understand the current one, which simplifies scaling and reasoning about the API.

Example: A Math Practice App

Suppose a math practice app stores algebra problems and student attempts. To read problem $42$:

GET /api/problems/42

The server could return:

{
  "id": 42,
  "topic": "linear equations",
  "prompt": "Solve 2x + 5 = 17",
  "difficulty": "easy"
}

When the student submits an answer, the client creates a new attempt:

POST /api/attempts

with a body such as:

{
  "problemId": 42,
  "answer": "x = 6"
}

If accepted, the server might respond 201 Created and return the saved attempt. Notice the client is not calling a verb-heavy URL like /gradeAnswerNow — it is creating a new attempt resource and letting the method carry the action. The pattern is clear: problems and attempts are resources, URLs identify them, methods express the action, and the response says what happened.

When REST Is a Good Fit

REST fits when your system is naturally centered on resources and standard create-read-update-delete patterns. It is common when a frontend, mobile app, or another service needs structured access to data over HTTP — dashboards, e-commerce, learning platforms, internal tools, public developer platforms — and it shines when predictability matters more than packing everything into one flexible endpoint.

It is a weaker fit if the main task is not resource-oriented, if clients need very specialized query shapes, or if low-latency streaming is the real center of the design. In those cases, another API style may be simpler.

Concepts Students Often Confuse

• JSON does not equal REST. An API can use HTTP and JSON without following a resource-oriented design; what matters is resources by URL, methods for actions, meaningful status codes, and stateless requests.
• Verbs do not belong in URLs. /getProblem or /createAttempt can work technically but lose REST's main advantage — a predictable structure where resources and methods have different jobs.
• Stateless does not mean forgetful. The server can store plenty of data; it just should not rely on an unstated session-like conversation to make a single request meaningful.

Try Sketching One

Take a small workflow you already understand and list the nouns first. In a study app you might map problems, attempts, and students before thinking about endpoint details — that usually produces a cleaner design than starting with a long list of actions. If you can name the resources clearly, the REST design tends to come together fast.