Промежуточный проект: REST API с базой данных
Соберите всё изученное в один настоящий работающий сервис
- разбить небольшой проект на Express на слои (маршруты, данные, авторизация, тесты),
- хранить данные в SQLite с параметризованными запросами,
- проектировать CRUD-маршруты с правильными HTTP-глаголами и кодами статуса,
- добавлять валидацию и токен-аутентификацию как middleware,
- писать интеграционные тесты встроенным раннером и Supertest.
1. Что мы строим и как это связано
Наш проект - Bookshelf API: сервис, который хранит список книг и позволяет клиентам создавать, читать, обновлять и удалять их через HTTP. Эта четвёрка "создать, прочитать, обновить, удалить" настолько распространена, что у неё есть имя - CRUD, - и она почти идеально ложится на REST.
REST (Representational State Transfer) - это стиль HTTP API. Его суть: ваши данные - это набор ресурсов, у каждого есть URL, а действуете вы над ними HTTP-методами. Коллекция книг живёт по адресу /books; отдельная книга - по /books/42. Вы не придумываете глаголы в URL (/getBook, /deleteBook) - HTTP-метод уже говорит, что вы хотите.
Аналогия. Представьте API как стойку выдачи в библиотеке. Полки (база данных) хранят книги. Библиотекарь (ваше приложение Express) - единственный, кому можно трогать полки; посетители должны обращаться к нему. Некоторые запросы - "покажи книгу 42" - доступны всем. Другие - "добавь книгу", "выброси книгу" - требуют служебного бейджа (токена авторизации). А прежде чем внести новую книгу, библиотекарь проверяет, что форма заполнена верно (валидация). У каждого слоя своя единственная задача.
Вот как один запрос проходит через эти слои:
Читайте API слева направо: запрос проверяется, валидируется, обрабатывается, и лишь затем доходит до данных. Разделение этих обязанностей и делает промежуточный проект поддерживаемым, а не одним огромным запутанным файлом.