What Is a REST API? Explained for frontend developers

What is an API, in plain terms?

API stands for Application Programming Interface. Strip the jargon: it is an agreement that lets one program use another program's capabilities without either one knowing the other's internals.

The version you already know: when a weather app shows today's temperature, its programmers did not build weather satellites. They asked a weather *service's API* — "give me the temperature for Dera Ismail Khan" — and the service answered with a number. The app never sees the satellites, the databases, or the models; it only sees the agreed question and the agreed answer.

A web API does this over HTTP, the same protocol your browser uses. Your React components render data — course titles, prices, user names. A REST API is where that data lives and how your frontend asks for it.

What does "REST" actually mean?

REST stands for REpresentational State Transfer — a name nobody needs to memorise, because the idea is simple: the server holds resources, and the client transfers representations of their state.

In plainer terms, REST is a set of conventions for building web APIs, and the conventions are:

1. Client–server. The frontend (client) and the data-holder (server) are separate programs. They only communicate through requests.
2. Stateless. Each request carries everything the server needs. The server does not remember your previous requests — like a shopkeeper with no memory, served perfectly if every customer states their full order each time.
3. Uniform interface. Resources are named by URLs, manipulated with a small fixed set of methods, and represented in a standard format. Learn the pattern once, read any REST API.
4. Cacheable. Responses can say "you may reuse this for 60 seconds", so the client does not re-ask for unchanged data.

You do not need to recite these in an interview tomorrow. You need the working summary: REST APIs expose named things (resources) at URLs, you act on them with HTTP methods, and data travels as JSON.

What is an endpoint?

An endpoint is a URL where the API listens. The convention that makes REST readable: endpoints are nouns naming resources, in plural for collections:

Three rules keep endpoints clean:

• Plural nouns, not verbs. /api/courses — never /api/getCourses or /api/fetch_all_courses. The verb belongs in the HTTP method, not the URL.
• Hierarchy reads left to right. /api/courses/1/lessons is "course 1's lessons" — general to specific, like folders.
• One resource, one URL. The same course is always at /api/courses/1, whether you are reading it, updating it or deleting it. What changes is the method, which is the next section.

What do GET, POST, PUT, PATCH and DELETE do?

HTTP methods are the verbs. Five cover nearly everything:

Two subtleties beginners trip on:

• GET never changes anything. It only reads. If your "delete" is a GET request with ?action=delete, that is not REST — and it is dangerous, because browsers, crawlers and caches all assume GET is safe to repeat.
• POST vs PUT vs PATCH. POST *creates* (the server assigns the new id). PUT *replaces* the whole resource (you send the complete new version). PATCH *modifies* part of it (you send only the changed fields). In practice many APIs use POST and PATCH and rarely PUT — but knowing the distinction keeps you from misusing them.

What does the server send back?

Two things: a status code and usually a JSON body.

Status codes are three-digit verdicts, grouped by their first digit:

The habit to build now: read the status code before the body. A 404 with a helpful JSON error is still a 404 — your code must branch on the code, not on parsing the body and hoping.

JSON (JavaScript Object Notation) is the usual body format — objects and arrays as text:

{
  "id": 1,
  "title": "HTML & CSS Foundations",
  "level": "Beginner"
}

JSON is a subset of JavaScript object syntax, which is why frontend developers feel at home: JSON.parse() turns it into a real object, JSON.stringify() turns an object back into text for sending.

Worked example: run a real course API on your machine

Everything above becomes concrete in about thirty lines. Save this as server.js — it uses only Node's built-in http module, no packages to install — and run it with node server.js:

const http = require('node:http');

const courses = [
  { id: 1, title: 'HTML & CSS Foundations', level: 'Beginner' },
  { id: 2, title: 'JavaScript Essentials', level: 'Beginner' },
];

const server = http.createServer((req, res) => {
  const url = new URL(req.url, 'http://localhost:3000');

  if (req.method === 'GET' && url.pathname === '/api/courses') {
    res.writeHead(200, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify(courses));
  } else if (req.method === 'GET' && url.pathname.startsWith('/api/courses/')) {
    const course = courses.find(c => c.id === Number(url.pathname.split('/')[3]));
    if (course) {
      res.writeHead(200, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify(course));
    } else {
      res.writeHead(404, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify({ error: 'Course not found' }));
    }
  } else if (req.method === 'POST' && url.pathname === '/api/courses') {
    let body = '';
    req.on('data', chunk => body += chunk);
    req.on('end', () => {
      const course = { id: courses.length + 1, ...JSON.parse(body) };
      courses.push(course);
      res.writeHead(201, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify(course));
    });
  } else {
    res.writeHead(404, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ error: 'Not found' }));
  }
});

server.listen(3000, () => console.log('listening on 3000'));

Now talk to it with curl — a command-line tool for making HTTP requests. Each pair below is the actual output of a real run (Node.js v24, curl 8.5):

Read the collection:

curl http://localhost:3000/api/courses

[{"id":1,"title":"HTML & CSS Foundations","level":"Beginner"},{"id":2,"title":"JavaScript Essentials","level":"Beginner"}]
HTTP 200

Read one resource:

curl http://localhost:3000/api/courses/1

{"id":1,"title":"HTML & CSS Foundations","level":"Beginner"}
HTTP 200

Ask for what does not exist — note the 404 arrives *with* a JSON body explaining it:

curl http://localhost:3000/api/courses/99

{"error":"Course not found"}
HTTP 404

Create a resource — -X POST sets the method, -H sets the JSON content header, -d sends the body:

curl -X POST http://localhost:3000/api/courses \
  -H "Content-Type: application/json" \
  -d '{"title":"React From Scratch","level":"Intermediate"}'

{"id":3,"title":"React From Scratch","level":"Intermediate"}
HTTP 201

Run the first GET again and the collection now holds three courses — the POST really stored it (in memory; restart the server and it resets, which is exactly why real APIs use databases — the subject of the Node course).

Expected result: you have made all five kinds of REST conversation happen — list, read one, miss (404), create (201) — against a server running on your own machine. That is what every frontend "loading…" spinner is waiting on.

How does a frontend page call it?

curl was the manual version. In a page, fetch does the same job — here reading the course list into a React-style render:

fetch('http://localhost:3000/api/courses')
  .then(res => {
    if (!res.ok) throw new Error('HTTP ' + res.status); // read the code first
    return res.json();
  })
  .then(courses => {
    courses.forEach(c => console.log(c.id, c.title));
  })
  .catch(err => console.error('Request failed:', err.message));

Expected result (with the server running): the console prints 1 HTML & CSS Foundations and 2 JavaScript Essentials. Three things to notice, because they are the whole frontend-API discipline in miniature: check res.ok (the status code) before touching the body; .json() parses the envelope; .catch() handles the network failing, which is different from the server answering 404.

Common mistakes

• Verbs in URLs. /api/getCourses or /api/deleteCourse/1 — the method already says the verb. Nouns in the URL, verbs in the method, always.
• Ignoring the status code. Parsing the body without checking res.ok first means a 404 error page gets treated as data. Code first, body second.
• POST for everything. Using POST to read, update and delete "because it works" throws away the conventions that make APIs predictable — and breaks caching, which only applies to GET.
• Forgetting the JSON content header. A POST with a JSON body but no Content-Type: application/json header arrives as mystery text; most servers reject it with 400. The header is part of the contract.
• Putting secrets in frontend code. API keys pasted into a React component ship to every visitor's browser. Keys belong on a server (yours), never in code the client downloads.

Frequently asked questions