Checkpoint: Build a REST API

Reviewed & published by Brayan K

This checkpoint ties the course together by having you build one small Express REST API that validates input, protects a route with a JWT, and logs every request — the same layers that power real production services.

Part of the free Node.js course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

First you'll review everything you've learned, then take on a multi-step build challenge with a starter and a full solution, and finally test your understanding with a short checkpoint quiz before moving on to the capstone.

What You've Learned So Far

• Streams — processing data piece by piece without loading it all
• Routers — splitting an app into modular, mountable route files
• Validation — rejecting bad input with clear 400 responses
• JWT auth — signing tokens and protecting routes with middleware
• File uploads — accepting multipart/form-data with Multer
• Logging — structured logs with pino and HTTP logs with morgan
• Mongoose — schemas, models, and CRUD against MongoDB
• Deployment — env config, PM2, Docker, and graceful shutdown

🔍 Warm-Up: the Core Logic, Running

Before the full build, here are the two ideas at the heart of the API — input validation and token issue/verify — as a small runnable program (no server needed), so you can confirm the logic with real output:

const jwt = require('jsonwebtoken');
const SECRET = 'checkpoint-secret';

// The two pieces of logic at the heart of the API, runnable without a server.

// 1) Validation (the body of POST /books)
function validateBook(body) {
  const errors = [];
  if (!body.title || typeof body.title !== 'string') errors.push('title is required');
  if (body.year !== undefined && typeof body.year !== 'number') errors.push('year must be a number');
  return errors;
}
console.log('Good body:', validateBook({ title: 'Node Mastery', year: 2024 }));
console.log('Bad body: ', validateBook({ year: 'nope' }));

// 2) Issue + verify a token (login + auth middleware)
const token = jwt.sign({ sub: 1, name: 'reader' }, SECRET, { expiresIn: '1h' });
const claims = jwt.verify(token, SECRET);
console.log('Logged in as:', claims.name);

Your mission, step by step

• Add a logging middleware that prints LOG <method> <url> for every request.
• Build a validated POST /books: title required (string), year optional (number), else 400.
• Add POST /login that signs a JWT for a demo user and returns { token }.
• Write a JWT auth middleware that reads the Bearer header and rejects missing/invalid tokens with 401.
• Protect GET /books with that middleware and return { user, books }.

// Install once:  npm install express jsonwebtoken
const express = require('express');
const jwt = require('jsonwebtoken');
const SECRET = 'checkpoint-secret';

const app = express();
app.use(express.json());

const books = [];

// STEP 1 — a logging middleware that prints "LOG <method> <url>" for every request.
app.use((req, res, next) => {
  // TODO: console.log the method and url, then call next()
});

// STEP 2 — a VALIDATED POST /books.
//   - title is required and must be a string  -> else 400 { errors: [...] }
//   - year, if present, must be a number      -> else 400
//   - on success, push { id, title, year } and respond 201 with the book
app.post('/books', (req, res) => {
  // TODO: validate req.body, then create the book
});

// STEP 3 — POST /login issues a JWT for a demo user.
app.post('/login', (req, res) => {
  // TODO: sign { sub: 1, name: 'reader' } and return { token }
});

// STEP 4 — a JWT auth middleware: read "Authorization: Bearer <token>", verify it.
function auth(req, res, next) {
  // TODO: 401 if missing/invalid, else set req.user and call next()
}

// STEP 5 — a PROTECTED GET /books that returns { user, books }.
app.get('/books', auth, (req, res) => {
  // TODO: respond with the logged-in user's name and the books array
});

app.listen(3000, () => console.log('LOG api up'));

Here's a complete, working implementation. The comment at the bottom shows the exact output produced by hitting the routes in order — a created book, a rejected bad book, a blocked unauthenticated GET, a login, and finally an authorized GET:

📝 Checkpoint Quiz

Test yourself. Think through each answer first, then expand it to check.

Because middleware runs in order. express.json() parses the request body into req.body. If a route runs before it, req.body is still undefined and validation breaks.

400 Bad Request for invalid input (missing title, wrong type) and 401 Unauthorized for a missing or invalid token. They tell the client whether to fix the data or to authenticate.

Between the path and the handler: app.get('/books', auth, handler). Express runs auth first, and it can send a 401 (and skip the handler) when the token is missing or invalid.

It reads the Authorization header, splits off the "Bearer " prefix, and passes the remaining token to jwt.verify(token, SECRET), attaching the decoded claims to req.user.

In-memory data is lost on every restart and isn't shared across instances. Replace the array with a Mongoose model — await Book.create(...) and await Book.find() — to persist the data in MongoDB.

morgan as middleware logs every HTTP request automatically; pino writes your own structured app events. Piping morgan into pino gives you one consistent JSON format.

Pro Tips

• 💡 Validate at the edge: reject bad input as early as possible with a clear 400 so the rest of your handler can trust the data.
• 💡 One reusable auth middleware: write it once and drop it in front of every route that needs a logged-in user.
• 💡 Layer your logs: morgan for the access log, pino for app events — both as JSON so they ship to one place.

🎉 Checkpoint Complete!

• ✅ You combined validation, JWT auth, and logging into one Express API
• ✅ Validation failures return 400; missing/invalid tokens return 401
• ✅ The auth middleware reads the Bearer header and guards the protected route
• ✅ A request logger records every method and URL
• ✅ Swapping the array for a Mongoose model makes the data persistent
• ✅ You reviewed streams, routers, validation, uploads, logging, mongoose, and deployment

Practice quiz

Continue this course

• Previous: Deploying Node (PM2 & Docker)
• Next: Scaling with the cluster Module — Use every CPU core by forking worker processes that share a port
• Quick reference: Node.js cheat sheet

Frequently asked questions

Which middleware order should I use in this API?

Order matters in Express because middleware runs top to bottom. Put express.json() first so req.body is parsed before any route reads it, then your request logger so it records every request, then your routes. For protected routes, the auth middleware goes between the path and the handler — app.get('/books', auth, handler) — so auth runs first and can reject the request with a 401 before the handler ever executes. A general rule: parsing and logging are app-level (app.use) and run for everything; auth is route-level and guards only the endpoints that need a logged-in user.

Why return 400 for validation errors but 401 for auth failures?

HTTP status codes communicate what went wrong. 400 Bad Request means the client sent something malformed or invalid — here, a missing title or a non-numeric year — so the fix is to correct the request body. 401 Unauthorized means the client isn't authenticated — no token, or an invalid/expired one — so the fix is to log in and send a valid token. Using the right code lets clients and tools react correctly: a 400 says 'fix your data', a 401 says 'authenticate first'. Returning 200 with an error message buried in the body, by contrast, hides failures from anything inspecting the status.

How would I connect this API to a real database?

Right now the books live in an in-memory array, so they vanish on restart. To persist them, replace the array with a Mongoose model (from the MongoDB lesson): define a Book schema, compile it into a model, and swap books.push(book) for await Book.create({ title, year }) and the array read for await Book.find(). Make the route handlers async, await the database calls, and wrap them in try/catch (or an async error handler) so a database failure returns a 500 instead of crashing the process. The validation, JWT, and logging layers stay exactly the same.

How should I test a REST API like this?

Start by exercising it manually with curl or a REST client (Postman, the VS Code REST extension): POST a valid book, POST an invalid one to confirm the 400, GET without a token to confirm the 401, log in to get a token, then GET with the Authorization: Bearer header to confirm the 200. For automated tests, a library like supertest lets you fire requests at your Express app in-process and assert on the status and JSON body, so you can verify validation, auth, and the happy path on every commit — exactly the flow shown in this checkpoint's solution output.