Building your first REST API with Node.js: a step-by-step guide

Every backend developer needs to build an API. Here is a practical guide to building your first REST API.

If you are learning backend development, building a REST API is one of the most practical projects you can undertake. It teaches you HTTP, data modeling, error handling, and how clients and servers communicate.

You will need Node.js installed and a code editor. We will use Express because it is minimal and widely used. The API will manage a simple resource with standard CRUD operations.

Start by setting up the project: initialize npm, install Express, create your first server file. Define your routes. Connect to a database.

The key concepts to understand: request and response objects, middleware, route parameters, query strings, status codes, and error handling.

At CEA, we build APIs in multiple tracks because understanding how data moves between client and server is fundamental.

Plan the resource before writing code. Suppose the API manages students: what fields does a student have — id, name, email, cohort, enrolled date? Which operations make sense — list all, get one, create, update, delete? This mapping between nouns (resources) and verbs (HTTP methods) is the heart of REST: GET /students lists them, GET /students/42 fetches one, POST creates, PUT or PATCH updates, DELETE removes. Getting this vocabulary right early prevents the messy rewrites that come from treating URLs as whatever occurred to you mid-coding.

Status codes are your API's honesty. Return 201 for successful creation, not 200-with-a-message. Return 400 with a helpful body when input fails validation; 404 when a resource does not exist; 401 versus 403 distinguishes 'who are you?' from 'I know who you are and you cannot do this'. Frontend teams build entire error-handling flows on these signals — an API that returns 200 for everything, including failures, forces consumers into parsing response bodies to guess what happened. Write errors consistently: a JSON object with code, message, and optional field-level details becomes contract, not accident.

Middleware is where Express earns its keep. Validation middleware checks incoming data before it reaches your handlers. Authentication middleware verifies tokens and attaches the user to the request. Logging middleware records who did what. Understanding that every request flows through a pipeline of functions — each able to inspect, modify, short-circuit or pass along — transforms Express from magic into something you can reason about. Build one small middleware yourself early (even just a request logger) and the concept locks in permanently.

Data persistence choices for learning: start with SQLite if you want zero setup, or PostgreSQL via a free hosted tier if you want realistic experience — both teach the same SQL fundamentals that transfer everywhere. Use an ORM like Prisma initially so your schema lives in versioned files and migrations stop being terrifying. Later, learn what SQL the ORM actually generates, because debugging production issues eventually requires reading raw queries. Whatever you choose, never store passwords in plain text — hash with bcrypt — and validate every field's type, length and format at the boundary.

Then go beyond happy path thinking. What happens when two requests try to update the same record? When the database connection drops mid-request? When someone sends a 10MB JSON payload? Add request size limits, timeouts, and rate limiting even in toy projects — they are habits. Document your API as you build (an OpenAPI file or even a well-kept README with curl examples), write tests for each endpoint including failure cases, and deploy it publicly on a free tier. An API with documentation, tests and a live URL is a portfolio piece; the same code sitting untested on your laptop is homework.