Skip to content

Intermediate Project: A REST API with a Database

Beginning of the lesson

Intermediate Project: A REST API with a Database

Assemble everything you have learned into one real, working service

Big Idea: A REST API is not a single trick - it is a set of small skills working together. In this capstone you will build one coherent project, a Bookshelf service, that stores books in a real database, exposes them through clean HTTP routes, validates what clients send, protects writes behind a token, and proves it works with automated tests. Nothing here is brand new; the goal is to compose the pieces you already know into something you could deploy.
By the end you will be able to:
  • lay out a small Express project into layers (routes, data, auth, tests),
  • persist data in SQLite with parameterised queries,
  • design CRUD routes that use correct HTTP verbs and status codes,
  • add validation and token authentication as middleware,
  • write integration tests with the built-in test runner and Supertest.

1. What we are building, and how it fits together

Our project is a Bookshelf API: a service that keeps a list of books and lets clients create, read, update, and delete them over HTTP. That "create, read, update, delete" quartet is so common it has a name - CRUD - and it maps almost perfectly onto REST.

REST (Representational State Transfer) is a style for HTTP APIs. Its core idea: your data is a set of resources, each with a URL, and you act on them with HTTP methods. A book collection lives at /books; a single book lives at /books/42. You do not invent verbs in the URL (/getBook, /deleteBook) - the HTTP method already says what you want.

Analogy. Think of the API as a library front desk. The shelves (the database) hold the books. The desk clerk (your Express app) is the only one allowed to touch the shelves; visitors must ask the clerk. Some requests - "show me book 42" - are free for anyone. Others - "add a book", "throw one out" - require a staff badge (the auth token). And before the clerk files a new book, they check the form is filled in correctly (validation). Every layer has one job.

Here is how a single request flows through those layers:

Client curl / browser Express app auth check token validate check body route handler business logic SQLite database books table request JSON response
Each request passes through auth and validation before the handler touches the database; the reply travels back as JSON.

Read the API from left to right: a request is checked, validated, handled, and only then does it reach the data. Keeping those responsibilities separate is what makes an intermediate project maintainable instead of one giant tangled file.

Continue this lesson on YourAIZone

The full lesson has the complete explanation, worked examples, common mistakes, tests with instant checking and an AI tutor. Start right away as a guest, or create an account to keep your progress.

In the full lesson

  • The complete explanation
  • Worked examples
  • Common mistakes and how to avoid them
  • Test questions: 15
  • AI tutor that answers questions about the topic
  • Progress tracking for students, parents and teachers